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Abstract  -  This  paper  describes  an  algorithm  for  an  aulomaicd  conversion  of  a  unification  parser  for  natural  language 
into  an  efficient  uruficauon  generator  for  the  sjnic  language.  T  he  scope  of  applicability  of  the  algonthm  is  discussed  and 
possible  avenues  of  extension  arc  suggested  'Ifie  algonlhm  is  tested  on  an  actual  grammar  derived  from  a  larger  string 
grammar  for  English. 

1.  Motivation 

The  purpose  of  ihis  research  is  lo  explore  possibiiiiies  of  an  aulomaied  derivation  of  an  efficient  unification- 
based  generator  for  a  natural  language  (Enghsh,  Japanese)  from  a  unification-based  parser  for  the  same  language. 
Although  the  idea  of  reversible  Prolog  programs  is  not  a  new  one,  there  has  always  been  the  problem  of  efficiency. 
This  paper  describes  some  preliminar\  results  obtained  from  tlie  e.xpennienis  with  reversing  a  Prolog  parser  for  a 
substantial  subset  of  English  into  an  efficient  generator.  Similar  expenmenis  with  Japanese  parser  arc  under  way. 
The  starting  point  of  the  experiment  is  a  su-ing  grammar  for  English  developed  by  the  NYU's  Linguistic  String  Pro- 
ject (Sager  1981)  and  subsequently  used  as  a  basis  of  the  string  parser  in  the  Proteus  Project  (Gnshman,  ei  al.).  The 
string  parser,  which  produces  a  regularized  operator-argument  pcirsc,  is  first  converted  into  an  equivalent  unification 
parser  written  in  Prolog.  This  involves  u-anslating  the  BNF  part  of  the  siring  grammar  (CF  syntax  +  regularization 
rules)  as  well  as  the  restriction  component  (specifying  context-sensitive  dependencies).  The  conversion  into  Prolog 
is  performed  according  to  certain  principles  which  are  aimed  at  assuring  a  "reversibility"  of  so-obtained  parser.  The 
Prolog  parser  can  be  subsequently  "compiled"  into  an  efficient  Prolog  generator  working  backwards:  from  regular- 
ized parse  forms  to  English  sentences.  To  obtain  a  Prolog  parser  (or  a  Prolog  program,  in  general)  working  in  the 
reverse,  requires  (barring  the  presence  of  non-reversible  operations,  such  as  arithmetic  operations)  some  manipula- 
tion of  the  clauses,  especially  the  ordering  of  the  literals  on  their  right-hand  side.  On  the  1988  CMU  MT  confer- 
ence, Dymetman  and  Isabelle  proposed  a  semi-automatic  process  in  which  the  non-terminals  in  the  right-hand  side 
of  the  productions  in  the  source  grammar  are  explicitly  marked  (manually)  for  the  order  in  which  they  should  be 
expanded  in  generation.  The  annotated  BNF  grammar  is  then  used  to  derive  both  a  Prolog  parser  and  a  Prolog  gen- 
erator. However,  the  semantic  component  of  the  grammar  is  not  fully  integrated  into  the  inversion  process.  The 
effect  is  that,  at  least  in  certain  ca.ses,  the  generator  must  rely  on  dynamic  goal  ordering  forcing  it  to  "freeze"  some 
goals  until  certain  variables  get  instantiated.  The  goal-freezing  mechanism,  however,  adds  a  substantial  overhead 
during  execution.  The  approach  taken  in  the  present  experiment  is  to  convert  the  Prolog  parser  in  which  both  the 
semantic  component  as  well  as  the  context-sensitive  resuictions  have  been  accommodated  into  a  single  executable 
program.  The  goals  of  this  research  can  be  stated  as  follows: 

(1)  Describe  the  conditions  under  which  the  unification-based  parser  is  reversible  to  form  an  efficient  generator 
without  the  need  to  write  a  separate  program.  This  includes  the  problem  of  reversibility  of  the  underlying 
grammar  formalism  on  which  the  parser  is  based. 

(2)  Specify  transformations  necessary  to  automatically  convert  a  parser  satisfying  the  conditions  set  up  in  (1) 
into  a  generator  that  would  be  at  least  as  efficient  the  parser.' 

2.  Converting  a  string  grammar  into  Prolog 

A  string  grammar  used  in  the  Proteus  Project  consists  of  (1)  context-free  BNF  component,  (2)  "semantic" 
rules  which  construct  the  regularized  parse  (semantic  rules  accompany  the  CF  rules),  and  (3)  the  restriction  com- 
ponent specifying  context-sensitive  and  other  constraints  imposed  upon  the  CF  component,  such  as  number  agree- 
ment between  phrases  and  verb  subcategorization  (types  of  object  strings  verbs  can  accept),  and  so  forth.  The  CF 


'  In  ihe  present  experiment  an  average  processing  time  for  a  15-word  sentence  ranged  between  0.10  and  0.70  seconds  per  parse  (for  pars- 
ing), and  between  less  than  0.01  and  0.25  seconds  per  sentence  (for  generation). 


component  is  iransformed  into  Prolog  using  a  standard  DCG  method  of  furnishing  the  non-terminals  with  variables 
binding  the  "input"  and  "output"  strings.  Thus,  the  BNF  production  N  ::=  Nl  N2  N3  is  translated  into  the  following 
definite  clause: 

n(Xl,X4)  :-  nl(Xl,X2),n2(X2.X3),n3(X3,X4). 

The  "semantic"  rules  accompanying  the  CF  productions  come  in  two  types:  local  and  non-local.  The  local  rules 
combine  the  translations  of  some  of  the  non-terminals  on  the  right-hand  side  of  a  production  into  the  translation  of 
the  non-terminal  on  the  left.  These  can  be  incorporated  into  the  Prolog  parser  by  adding  additional  literals  at  the  end 
of  the  clause,  for  example, 

n(Xl,X4J>j:-nl(Xl,X2,Pl),n2(X2,X3,P2),n3(X3,X4,P3),combine(PlJ>2,P3J'). 

where  the  variables  P,  PI,  P2  and  P3  will  be  bound  to  "translations"  of  N,  Nl,  N2  and  N3,  respectively.  Non-local 
"semantic"  rules  create  translations  of  left-hand  non-terminals  out  of  elements  that  may  not  be  available  on  the 
right-hand  side  of  the  production,  but  instead  are  pas.sed  over  from  other  productions.  For  example,  in 

n(Xl,X4J>) :-  nl(Xl,X2J'l),n2(X2,X3,P2),n3(X3,X4,Pl,P2,P). 

the  "semantics"  of  n3  is  not  formed  until  the  actual  expansion  of  n3  is  known.  Because  the  "semantics"  of  nl  and  n2 
are  lo  be  included  in  the  final  translation  for  n,  these  (PI  and  P2)  arc  passed  as  arguments  to  n3,  and  so  is  P.  Finally, 
the  restriction  component  is  incorporated  into  the  p;irscr.  Ai  this  time  only  a  limited  amount  of  resu-ictions  have 
be^n  added,  including  some  of  the  resiriciions  on  the  U'pcs  ol  object  strings  that  certain  verbs  can  take,  the  number 
agreement  and  some  consu-aints  goseming  ihc  placemcni  ol  .sentence  adjuncts. 

2.1.  Examples  of  translating  a  j>ramniar  \\itli  semantic  rules 

A  production  in  the  string  grammar  consists  of  the  contcM-lrec  pan  and  the  "semantic"  part  specifying  how  the 
"translations"  of  the  components  are  to  be  combined  lo  create  the  translation  of  the  head  non-terminal  on  the  right- 
hand  side. 

N  ::=  Nl  N2  N3    :<form  u-anslation  of  N  out  of  those  for  Nl,  N2  and  N3> 

There  are  two  basic  ways  of  specifying  the  u-anslaiion  ol  N:  local  and  non-local.  The  local  translation,  or  local 
semantics,  composes  the  translation  of  N  out  of  translations  of  Nl,  N2  and  N3  in  such  a  way  that  the  the  latter  three 
become  arguments  of  some  constant  function  f,  Productions  with  local  semantics  may  take  the  follov^ing  general 
form: 

N::=N1N2N3    :f(Nr,N2',N3') 

where  Ni'  denotes  the  "semantics"  (i.e.,  translation)  of  Ni.  In  this  case,  the  translation  into  Prolog  is  simple: 

n(Xl,X4,f(Pl,P2,P3))  :- nl(Xl,X2,Pl),n2(X2.X3,P2).n3(X3,X4.P3). 

As  an  example,  consider  (a  somewhat  simplified)  production  recognizing  the  left  adjunct  phrase  to  a  noun: 

<ln>  ::=  <tpos>  <qpos>  <apos>  <npos> 

:(<tpos>  <qpos>  <apos>  <npos>). 

This  rule  is  converted  into  the  following  Prolog  clause: 

ln(Ll,L5,[Pl,P2,P3,P4]):- 
tpos(Ll,L2,Pl), 
qpos(L2,L3,P2), 
apos(L3,L4J>3), 
nposCL4,L5,P4). 

Sometimes,  when  the  function  f  is  not  as  simple  as  the  list-building  primitive,  we  may  want  to  use  a  non-local  trans- 
lation (see  below).  For  example,  if  lists  translating  adjunct  components  need  to  be  spliced  in  rather  than  merely  jux- 
taposed, we  may  require  the  following  Prolog  clause  instead: 

ln(Ll,L5J'):- 

tpos(Ll,L2J'l), 
qpos(L2,L3,P2), 
apos(L3,L4,P3), 
npos(L4,L5,P4), 
#([P1,P2J'3J'4],P). 
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Productions  wiih  non-local  semantics  occur  when  the  translation  of  the  head  non-terminal  is  constructed  out  of  ele- 
ments which  are  unknown  or  unavailable  to  the  production,  or  require  special  handling  by  dedicated  routines  (such 
as  splice-in  #  above).  Such  producuons  give  rise  to  the  so-called  "chain  rules''^  where  the  translation  of  the  head 
non-terminal  is  not  constructed  immediately  but  instead  it  is  passed,  along  with  the  translations  of  some  of  the 
right-hand  side  elements,  to  some  other  production  or  a  dedicated  routine  for  the  final  assembly.  Except  for  the  case 
illustrated  above,  rules  with  non-local  "semantics'  usually  involve  at  least  two  productions,  which  may  take  the  fol- 
lowing general  form: 

N  ::=N1N2N3  :XP  P(Nr,N2')  (N3') 

N3::=N4  :XP>.Q  Q(P,N4') 

where  Ni'  denotes  "semantics"  (or  u-anslaiion)  of  Ni,  and  P  and  Q  are  variables.  The  corresponding  Prolog  clauses 
are  as  follows: 

n(Xl,X4J>)  :-  nl(Xl,X2,Pl),n2(X2,X3,P2j.n3(X3,X4,Pl,P2,P). 
n3(Xl,X2,Pl,P2,Pj :-  n4(Xl,X2,P3),combine([Pl,P2,P3).P). 
or 

n(Xl,X4P):-nl(Xl,X2,Pl),n2(X2,X3,P2),n3(X3,X4,Pl,P2,P). 
n3(X  1  ,X2,P1  ,P2,f(Pl ,P2,P3)) :-  n4(X  1  ,X2.P3 ). 

For  example,  the  following  two  productions  Ironi  the  string  grammar: 

<assertion>  :;=  <subjeci>  <verb>  <obiect> 

:(<ob|eci>  <subieci>  <vc^b>). 
<object>  ::=  <nstgo> 

:(lambda  (subj  vh) 

(Ivb  (subject  subj)  (object  <nstgo>))) 

are  translated  into  two  clauses  in  Prolog: 

assertion(Al,A4J')  ;- 

subject(Al,A2J'l), 

verb(A2,A3P2), 

objeet(A3,A4,Pl,P2,P). 
object(01,02,Pl,P2,[P2,(subject,Pl],(ob|cct,P3]])  :- nstgo(01,02,P3). 

The  chain  rule  for  assertion  passes  an  unbound  copy  ol  the  translation  variable  P  to  the  object  clause,  along  with 
bound  translations  of  subject  and  verb,  PI  and  P2.  Object  clause,  when  called,  accommodates  the  latter  two  and  its 
own  translation  P3  into  the  final  translation  of  assertion  which  subsequently  binds  variable  P. 

The  reader  may  note  that  the  chain  rule  featured  in  this  example  could  be  reduced  to  a  non-chain  rule  with 
local  semantics  by  eliminating  non-terminal  object  and  rewniing  the  clause  defining  assertion  as  follows: 

assertion(Al,A4,[P2,[subject,Pl],[obje<:t,P3]])  :- 
subject!  A  l,A2J'l), 
verb(A2,A3,P2), 
nstgo(A3,A4J>3). 

We  call  this  mo'^e  path  compression  because  it  shortens  some  paths  in  the  parse  tree  by  eliminating  non-terminals 
from  the  grammar.  Path  compression  can  be  used  to  simplify  the  parser  code  during  the  code  normalization  process 
described  in  section  4.  One  obvious  reason  for  doing  so  is  the  fact  that  non-chain,  local -semantics  rules  frequently 
need  no  further  processing'  and  can  be  used  dircctl)  for  generation.  Even  so,  path  compression  must  be  used  care- 
fully, or  it  may  have  an  adverse  effect  on  the  program  performance.  For  one  thing,  path  compression  will  almost 
certainly  decrease  the  efficiency  of  the  parser,  since  it  would  replace  common  parts  of  certain  paths  by  a  number  of 
disjoint  paths,  thus  increasing  the  potential  backup  ratio.  Con.sequently,  it  may  decrease  the  efficiency  of  the  genera- 
tor if  the  same  parse  structure  can  activate  several  alternative  routes  for  generation.  This  latter  problem  can  be 
averted  by  merging  these  paths  as  long  as  they  carry  the  same,  unique  parse  structures.  The  problem  of  path 


^  We  borrow  this  term  from  Shieber  et  al.  (19S9;. 

'  Inversion  may  sull  be  reqmred  for  efficiency  reasons,  if  argumenis  lo  Lhe  btcrals  remain  in  cenam  mutual  dependencies. 
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compression  and  merging  is  further  discussed  in  seclion  4.3. 


2.2.  Translating  context-sensitive  restrictions  in  the  string  grammar 

An  imporiant  part  of  a  siring  grammar  are  conicxt-scnsiiivc,  and  other,  restrictions  imposed  upon  context-free 
productions  of  the  grammar  in  order  to  narrovv  ihcjr  applicahiliiy  m  certain  cases.  Among  these  restriction  are  the 
number  agreement  restriction  between  subject  and  the  lirst  verb  of  sentences,  various  restrictions  on  the  placement 
of  sentence  adjuncts,  restrictions  on  the  types  of  object  su'ings  a  verb  may  accept,  and  so  forth.  At  present,  no  gen- 
eral method  of  translating  these  restrictions  into  Prolog  code  is  proposed,  and  many  of  them  have  been  accommo- 
dated on  the  one-by-one  basis.  There  is  \^•ork  currently  in  progress  to  make  this  U"anslation  fully  automatic  too. 

3.  Reversing  a  Prolog  parser  for  generation 

In  principle,  a  Prolog  parser  can  work  in  re\erse,  that  is,  given  a  n  jularized  operator-argument  form  it  can 
generate  a  sentence,  or  sentences,  thai  would  have  been  parsed  into  this  form.  In  practice,  however,  a  bidirectional 
parser/generator  is  not  a  workable  idea,  and  the  parser  program  needs  to  be  "tuned"  for  generation.  A  number  of 
specific  translation  rules  have  been  dcNClopcd  that  transform  the  source  of  the  Prolog  parser  into  a  generator.  There 
are  generally  two  kinds  of  rules:  ( 1 )  these  that  actually  reverse  the  parser  by  changing  the  order  in  which  literals  in  a 
clause  are  expanded,  and  (2)  those  thai  prepare  ilie  parser  lor  inversion  compiling  it  into  a  "normal"  form  by  replac- 
ing groups  of  clauses  by  new  clauses  in  order  to  (a)  assure  invcrtibiliiy  of  the  parser  and  (b)  enhance  the  efficiency 
of  the  inverted  program.  We  discuss  ihe  inversion  process  first,  ignoring  for  a  moment  the  problem  of  non- 
inveriible  clauses.  Later,  v.e  point  out  some  "non-normal"  productions  that  may  occur  in  the  grammar,  and  subse- 
quently in  the  parser,  and  which  cannot  be  coped  with  adequately  by  the  inversion  algorithm.  We  suggest  vv-ays  how 
these  can  be  normalized  by  a  pre-processing  compilation  stage. 

The  way  in  which  the  inversion  process  affects  the  parser's  clauses  (which  correspond  to  productions  in  the 
grammar)  depends  on  how  the  "semantics"  of  the  head-literal  non-terminal  of  this  clause  have  been  defined.  For  the 
clauses  with  a  local  "semantics",  no  changes  need  to  be  done  for  their  use  in  the  generator.  A  clause  with  a  non- 
local "semantics",  on  ilie  other  hand,  needs  to  be  replaced  by  a  new  clau.se  with  the  same  head  literal,  but  with  its 
right-hand  side  literals  appropriately  rearranged.  For  example,  the  clause 

n(Xl,X4J')  :-  nl(Xl,X2,Pl),n2(X2,X3,P2),n3(X3,X4,Pl,P2,P). 

needs  to  be  replaced  by  the  new  one  in  which  the  literal  n3(X3,X4,Pl,P2,P)  appears  at  the  front  of  the  right-hand 
side,  in  other  words,  it  is  fronted.  The  reason  for  this  is  that  during  generation  the  binding  of  P  is  known  before  the 
bindings  to  any  other  variables  in  this  clause.  Because  P  is  consuucted  out  of  (among  others)  PI  and  P2,  the.se  will 
have  known  bindings  when  n3  returns.  Subsequently,  no  other  changes  are  required.  In  general  case,  however,  the 
process  of  literal  fronting  may  require  recursive  application  to  the  remaining  literals. 

3.1.  Some  examples  of  literal  reordering 

The  grammar  rules  with  their  "semantics '  defined  locally,  frequently  do  not  need  to  be  modified  at  all  for  the 
use  in  a  generator.  A  parser  clause  of  the  form  given  below,  for  example,  needs  no  tuning  for  the  use  in  a  generator. 

n(XI,X3,[PIIP2]) :-  nl(Xl,X2,Plj,n2(X2,X3,P2). 

On  the  other  hand,  if  any  of  the  literals  on  the  rhs  of  a  clause  contains  the  variable  that  is  expected  to  be  bound  to 
the  "translation"  of  the  non-terminal  on  the  Ihs,  then  this  literal  must  be  fronted  on  rhs,  i.e.,  it  must  be  fired  first  dur- 
ing generation.  Thus  having  a  clause  of  the  form: 

n(Xl,X3J') :-  nl(Xl,X2,Pl),n2(X2,X3,Pl,P). 
we  have  to  replace  it  by 

n(Xl,X3J>) :-  n2(X2,X3,Pl,P),nl(Xl,X2,Pl). 
Similarly, 

n(Xl,X4J>):-nl(Xl,X2,Pl),n2(X2,X3,P2),n3(X3,X4,P3),combine([PlJ>2J>3],P). 
is  replaced  by 

n(Xl,X4J>):-combine([Pl.P2,P3],P),nI(Xl,X2,PI),n2(X2,X3,P2),n3(X3,X4,P3). 
The  reader  may  note  that  fronting  of  combine  makes  sense  only  under  the  assumption  that  this  predicate  can  be  run 
backwards  itself,  that  is,  with  only  the  argument  P  bound.  If  this  is  not  the  case,  though,  we  have  to  modify  the 


clause(s)  defining  combine  by  manipulating  us  (ihcin  rhs's,  so  ihai  it  siaris  behave  more  like  decompose. 

3.2.  A  general  algorithm  for  literal  reordering 

The  algorithm  presented  below  describes  a  general  meihod  of  rearranging  the  literals  in  the  right-hand  side 
(rhs)  of  a  Prolog  clause.  As  the  result  of  applying  this  algorithm  to  a  Prolog  program,  one  obtains  a  fairly  efficient 
"inverted"  program.  In  many  cases  the  obtained  inverted  program  is  optimal,  that  is,  as  efficient  as  as  it  can  be  given 
the  set  of  available  transformations  that  can  be  applied  to  the  original:  clause  replacement,  clause  reordering  and 
literal  reordering.  The  algorithm  does  not  deal  v,ilh  irreversible  buiU-in  Prolog  primitives  such  as  arithmetics. 

3.2.1.  Essential  arguments 

Some  arguments  of  every  literal  arc  essential  in  the  sense  that  the  literal  cannot  be  exe  -uied  successfully 
unless  all  of  them  are  bound,  at  least  partially ,  at  the  time  of  execution.  For  example,  the  Hteral  roncai(X,Y,Z)  that 
concatenates  lists  X  and  Y  into  list  Z  can  be  executed  only  if  either  X  or  Z  is  bound.  An  argument  is  considered 
fully  bound  is  it  is  a  constant  or  it  is  bound  by  a  constant;  an  argument  is  partially  bound  if  it  is,  or  is  bound  by,  a 
functional  expression  (not  a  variable)  in  v,hich  at  least  one  variable  is  unbound.  We  may  also  define  the  degree  to 
which  an  argument  is  bound  (see  the  following  section).  If  concat  is  used  to  concatenate  lists  then  X  must  be  bound: 
if  it  is  used  to  decompose  lisLs  then  Z  must  be  bound.  In  general,  a  literal  may  have  several  alternative  (possibly 
overlapping)  sets  of  essential  arguments.  If  all  arguments  in  any  one  of  such  sets  of  essential  arguments  are  bound, 
then  the  literal  can  be  executed.  .Any  .set  of  essential  arguments  which  have  the  above  property  is  called  essential. 
We  shall  call  the  set  MSEA  of  essential  arguments  a  minimal  set  of  essential  arguments  if  it  is  essential,  and  no 
proper  subset  of  MSEA  is  essential.  If  any  of  MSEA's  of  a  given  literal  is  an  empty  set,  then  this  literal  needs  no 
essential  arguments,  which  mciins  it  can  be  executed  at  any  time,  even  if  none  of  its  arguments  is  bound.""  Out  of 
many  different  MSEA's  a  literal  may  have  two  subsets  will  be  of  speeial  interest  to  us:  these  which  define  the  du-ec- 
lion  in  which  the  literal  is  used:  forward  or  backward.  Concat(X,Y,Z),  for  example,  has  two  MSEA's:  MSEAl  = 
(X)  and  MSEA2  =  (Z).  When  the  variable  in  MSE.Al  is  bound,  then  concat  is  used  forward,  i.e.,  for  concatena- 
tion. When  the  variable  in  MSEA2  is  bound,  on  the  other  hand,  then  concat  is  used  to  decompose.  In  this  way,  the 
concept  of  invertibility  appears  well  defined.  Literals  that  have  less  than  two  MSEA's  are  not  reversible  but  then 
there  may  be  no  need  to  reverse  them.  Howe\er,  their  presence  in  a  Prolog  program  affects  the  reversibility  of  this 
entire  program  in  dramatically  different  ways.  I-MSEA  literals  must  always  have  their  only  MSEA  variables  bound 
before  they  can  be  executed.  If  the  only  MSEA  is  a  non-empty  set,  then  the  literal  is  not  reversible  and  must  be 
used  in  one  direction  only.  However,  if  a  1-MSEA  literal  has  an  empty  set  of  MSEA's  then  it  can  be  executed  at  any 
lime  whatever.  Arithmetic  operations  are  examples  of  1-MSEA  literals  with  a  non-empty  MSEA.  In  the  domain  of 
parsing,  lexicon  look-up  primitives  that  check  properties  of  specific  words  are  practically  irreversible.  Among  1- 
MSEA  literals  with  an  empty  MSEA  probably  the  most  common  are  those  recognizing  specific  terminals  in  the 
input,  such  as  tovo's  to(X,Yj  or  thati'  that(X,Yj  literals,  which  simply  remove  word  "to"  and  "that",  respectively, 
from  the  input  string.  0-MSEA  literals,  that  is,  those  that  have  no  MSEA  at  all,  can  never  be  executed  meaningfully, 
and  thus  must  be  considered  ill-formed.  V 

So  defined,  the  notion  of  the  set  of  essential  arguments  can  be  used  to  determine  the  invertibility  of  a  Prolog 
program,  but  the  concept  is  still  loo  weak  to  be  of  any  practical  use.  It  seems  that  any  literal  with  at  least  two 
MSEA's  can  be  reversed,  but,  as  we  shall  see,  this  requirement  can  be  further  relaxed.  This  can  be  accomplished  by 
introducing  a  generalized  notion  of  a  MSEA.  Before  we  move  to  do  this,  however,  we  need  to  define  two  auxiliary 
concepts  of  "in"  and  "out"  arguments. 

3.2.2.  In  and  out  arguments 

Arguments  in  a  literal  can  also  be  marked  as  being  either  "in"  or  "out"  depending  on  whether  or  not  they  are 
bound  at  the  lime  the  literal  is  executed  in  a  specific  direction.  Thus,  in  concat([a,b],[c,d]Z),  the  first  two  arguments 
are  "in",  while  the  third  is  "out".  The  roles  are  reversed  when  concat  is  used  for  decomposition,  as  in 
concat(X,Y,[a,b,c,d]).  In  a  more  general  case,  the  roles  of  "in"  and  "out"  arguments  do  not  exactly  reverse  when  ihe 
direction  of  computation  is  reversed.  It  may  be  noted,  however,  that  the  role  reversal  is  expected  for  2-MSEA 


'  An  empty  MSEA  should  nol  be  confused  » iih  ihe  siiuaiion  where  a  hicral  has  no  .MSE.A,  meaning  ii  could  never  be  evaluated  successful- 
ly, even  though  all  of  us  arguments  were  bound.  In  the  former  case,  the  set  of  MSE.'V's  conuins  an  empty  MSEA  as  one  of  its  elements;  in  the 
latter  case,  the  set  of  MSEA  itself  is  empty. 


literals  with  disjoini  MSEA's.  As  an  example  consider  ihe  liieral  subjeci(Al,A2,WHQ,NajM,P)  where  Al  and  A2 
are  input  and  output  stnngs  of  words,  WHQ  indicates  whether  the  subject  phrase  is  a  part  of  a  clause  within  a  wh- 
question,  MUM  is  the  number  of  the  subject  phrase,  and  P  is  the  final  translation.  Out  of  these  arguments  only  two 
are  essential:  Al  when  parsing  and  P  when  generating.  In  parsing,  the  "in"  arguments  are:  Al  and  WHQ,  the  "out" 
arguments  are  A2,  NUM  and  P;  in  generating,  the  "in"  arguments  are  P  and  WHQ,  the  "out"  arguments  are  A 1  and 
NUM.  In  generating,  A2  is  neither  "in"  nor  "out".  Thus,  upon  reversing  the  direction  of  computauon,  an  "out"  argu- 
ment does  not  automatically  become  an  "in"  argument,  nor  does  an  "in"  argument  automatically  become  an  "out" 
argument.  Below  is  the  general  algorithm  for  computing  "in"  and  "out"  status  of  arguments  in  any  given  literal  in  a 
Prolog  program. 

An  argument  X  of  liieral  pred(...X...)  on  the  rhs  of  a  clause  is  "in"  if 

(A)  it  is  a  constant;  or 

(B)  it  is  a  function  and  all  its  arguments  are  "in";  or 

(C)  it  is  "in"  or  "out"  in  some  previous  literal  on  the  rhs  of  the  same  clause,  i.e.,  1(Y)  :-  r(X,Y),pred(X);  or 

(D)  it  is  "in"  in  the  head  literal  L  on  Ihs  of  the  same  clause. 

An  argument  X  is  "in"  in  the  head  literal  L  =  prcd(...  X...)  of  a  clause  if  (A),  or  (B),  or 

(E)  L  is  the  top-level  literal  and  X  is  "in"  in  it  (knoun  apnon):  t)r 

(F)  the  argument  Y  occupying  X's  positK)n  is  "in"  in  all  occurrences  of  pred  on  the  rhs  of  any  clause  with  head 
predicate  predl  different  than  pred,  and  such  that  \  unifies  with  X. 

A  similar  algorithm  can  he  propo.sed  for  computing  "out"  arguments: 

(R)  An  argument  X  of  literal  pred(...X...)  on  the  rhs  of  a  clause  is  "out"  if  it  is  "in"  in  pred(...X...).  or  the  argument 
Y  occupying  X's  position  and  unifiable  with  X  in  the  Ihs  of  all  clauses  with  the  head  literal  pred(...Y...)  is 
either  "in"  or  "out". 

(L)  An  argument  X  of  literal  pred(...X...)  on  the  Ihs  of  a  clau.se  is  "out"  if  it  is  "in"  in  pred(...X...),  or  it  is  "out"  in 
literal  predl(...X...)  on  the  rhs  of  this  clause,  providing  that  prcdl  *  pred  (again,  wc  must  take  provisions  to 
avoid  infinite  descend,  c.f.  (F)  in  "in"  algorithm). 

In  addition,  we  may  note  that  an  argument  which  is  a  functional  expression  (containing  variables  and  possibly 
further  functional  expressions)  is  (fully)  "out"  iff  each  of  its  own  arguments  is  (fully)  "out". 

At  first,  the  above  steps  may  appear  too  weak  to  determine  "out"  status  for  arguments  in  recursive  definitions. 
For  instance,  we  do  not  know  whether  a  recursion  stops  and  how  the  arguments  are  bound  until  we  actually  trace  the 
entire  process  and  see  that  the  recursion  stops  successfully.  Hov^cver,  if  it  does  not  stop  successfully,  i.e.,  it  either 
fails  or  loops  forever,  then  the  question  of  "out"  status  of  arguments  insolved  becomes  irrelevant.  On  the  other  hand, 
if  it  does  stop,  our  method  will  correctly  predict  the  status  of  "out"  arguments.  As  an  example,  consider  the  follow- 
ing recursive  situation: 

1(...) :-  ...,pred(A,Bj, ... 

pred(fun(X),Y) :-  pred(X,Y). 
pred(const,consl). 

The  algorithm  presented  above  will  predict  that  B  is  an  "out"  argument  in  pred(A,B)  on  the  rhs  of  the  first  clause 
(providing  the  two-clause  definition  below  comprises  of  all  the  clauses  with  pred  on  Ihs).  Obviously,  the  only  way 
Ihe  recursive  rule  is  going  to  stop  without  failure  is  to  fire  the  stop  condition  provided  by  pred(const,const).  In  the 
case  this  does  not  happen,  we  are  not  interested  in  the  status  of  A  and  B  at  all.  In  addition,  we  ignore  all  clauses  that 
contain  an  explicit  fail  literal  among  ihcu-  rhs  literals. 

In  practice  we  do  not  need  this  elaborate  general  algorithm,  and  the  problem  of  "in"  and  "out"  arguments  can 
be  localized  within  a  single  clause.  The  simplified  version  of  the  above  algonthm  that  will  be  used  in  the  present 
experiment  is  as  follows. 

An  argument  X  of  literal  pred(...X...)  on  the  rhs  of  a  clause  is  "in"  if 

(A)  it  is  a  constant;  or 

(B)  it  is  a  function  and  all  its  arguments  are  "in";  or 
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(C)  il  is  "in"  or  "out"  in  some  previous  literal  on  the  rhs  of  the  same  clause,  i.e.,  1(Y) :-  r(X,Y),pred(X);  or 

(D)  it  is  "in"  in  the  head  literal  L  on  Ihs  of  the  same  clause  (explicitly  set). 

Some  comment  in  order,  regarding  the  point  (D)  of  the  above  algorithm.  Although  the  "m"  arguments  of  the  head 
literal  must  be  known  before  the  right-hand  side  literals  of  this  clause  can  be  reordered,  we  do  not  specify  how  this 
information  is  to  be  obtained.  The  more  general  algorithm  given  earlier  required  full  analysis  of  the  sialic  AND/OR 
space  of  the  program  to  determine  "in"  arguments.  For  the  simplified  version  of  the  algorithm  we  are  left  with  two 
basic  options.  The  first  of  these  requires  that  we  know  apriori  which  arguments  of  the  head  literal  of  any  clause  are 
expected  to  be  "in"  during  generation.  The  other  option  requires  only  that  we  know  the  "in"  status  of  the  argumenis 
in  the  head  of  top-level  clause.  As  the  process  of  program  inversion  progresses  from  the  top-level  clause  to 

the  clauses  invoked  from  it,  the  information  about  "in"  arguments  is  passed  along. 

We  also  need  a  more  practical  method  of  computing  "out"  arguments.  This  is  of  a  sp'  cial  significance  because 
the  ability  to  determine  "out"  arguments  will  be  crucial  for  computing  the  generalized  sets  of  essential  arguments,  as 
discussed  in  the  following  se^uon.  The  centerpiece  of  the  algorithm  for  determining  "out"  arguments  in  a  Prolog 
clause  is  the  recursive  step  of  (R)  above,  with  the  stop  condition  provided  by  (L).  Even  though  (L)  may  not  look  as  a 
solid  stop  condition,  we  have  been  able  to  determine  that  there  arc  actually  three  types  of  situations  where  the  recur- 
sion stops  with  an  argument  X  being  marked  as  "out".  The  simplest  case  occurs  when  a  variable  X  is  bound  to  a 
constant  expression  as  the  result  of  the  unification  of  the  literal  containing  X  with  a  Ihs  occurrence  of  the  same 
literal  containing  a  constant  expression  in  X's  position.  Thus,  in  noun(Nl,N2,Num,P)  the  arguments  Num  and  Fare 
"out"  because  they  are  matched  against  consuinis  in  all  Ihs  occurrences  of  noun,  for  example 
noun([johnlN],N,sg,john).  The  second  type  of  situation  occurs  when  X  is  unified  with  an  "in"  argument.  The  gen- 
eral patterns  is  this:  pred(X,Y),  with  X  "in"  and  Y's  status  unknown,  is  unified  with  pred(f(X),X),  and  thus  Y 
becomes  "out".  For  example,  in  the  noun(Nl,N2,Num,P)  given  above,  N2  becomes  "out"  whenever  Nl  is  "in".  We 
may  note  here  that  the  "out"  status  of  an  argument  may  depend  on  the  "in"  status  of  other  arguments,  and  thus,  ulti- 
mately, on  the  "direction"  in  which  a  program  is  run  (Shoham  and  McDermott  1984).  The  final  possibility  is  when  a 
variable  receives  a  partial  binding,  that  is,  it  is  bound  by  a  functional  term  which  may  contain  some  unbound  vari- 
ables. In  other  words,  pred(X,Yj  is  unified  with  pred(X,f(const,Z))  or,  in  a  still  more  general  case,  with 
pred(X,f(Z,W)).  The  funcuonal  expression  returned  on  Y  may  be  entirely  sufficient  for  binding  an  essential  argu- 
ment in  some  other  literal  predl(Y,V).  Thus  Y  in  pred(X,Y)  can  be  marked  as  "out",  though  with  a  warning:  if  Y  is 
further  used  by  predl(Y,V)  to  determine  the  "out"  status  of  V  then  we  must  remember  that  the  functional  expression 
binding  Y  contains  a  possibly  still  unbound  variable  in  it.  For  example,  if  Y  is  bound  to  f(constZ),  where  Z  is 
unbound,  then  unifying  predl(Y,V)  with  predl(f(const,Z),Z)  does  not  make  the  variable  V  "out"!  On  the  other 
hand,  after  unifying  with  predl(f(const,Z),const),  we  get  V  "out"  all  right.  There  are  also  situations  when  none  of 
the  above  exuemes  would  happen:  for  example  we  may  unify  with  predl(f(constl,f(const2,Z)),f(consl2,Z)),  obtain- 
ing a  partial  "out"  binding  for  V.  In  general,  we  may  introduce  the  notion  of  the  degree  of  binding,  defined  as  fol- 
lows. A  variable  X  in  predp(...X...)  is  "out"  bound  lo  the  degree  n,  where  n  is  a  non-negative  integer,  if  n  is  the 

length  of  the  shortest  path  of  calls  pred^^.X^...),  prcd,(X,,,Xj),  pred,(X,,XO pred^(X^  ,,X^),  such  that  X_ ,  is 

"in",  and  X  is  partially  "out"  in  pred  ,  except  for  X^  which  is  not  "out"  in  pred^.  If  no  such  shortest  path  exists  ih^ 
X  is  fully  bound  with  respect  to  the  given  program.  A  variable  bound  to  the  degree  0  is  unbound.  The  partial  "out" 
status  of  some  arguments  is  important  in  analysing  some  literals,  including  recursive  ones.  For  example,  the  noun 
literal  discussed  above  will  have  Nl  partially  "out"  when  N  is  unbound  and  P  is  "in".  As  another  example  consider 
the  list  concatenation  @(X,YZ)  implemented  as 

@([]a-«. 
@([X1L1],L2,[XIL3]):-@(L1,L2,L3). 

Here  @(X,Y,Z)  will  produce  a  partially  bound  Z  when  it  is  called  with  X  "in"  and  Y  unbound.  This  allows  us  to 

conclude  that  the  only  essential  arguments  of  @  are  either  X  or  Z. 

The  revised  formulation  of  steps  (L)  and  (Rj  for  computing  "out"  arguments  in  a  literal  is  given  below. 

(R)  An  argument  X  of  literal  pred(...X...)  on  the  rhs  of  a  clause  C  is  "out"  if  it  is  "in"  in  pred(...X...),  or  the  argu- 
ment Y  unifiable  with  X  in  the  Ihs  of  all  clauses  with  the  head  literal  pred(...Y...)  is  either  "in",  or  "out",  or 
partially  "out"  as  f(Z)  and  there  is  a  literal  predl(...Zl...)  following  pred(...X...)  in  the  rhs  of  C  such  that  Zl 
unifies  with  Z  and  Zl  is  "out"  in  pred  1 . 

(L)  An  argument  X  of  literal  pred(...X...)  on  the  Ihs  of  a  clause  is  "out"  if  it  is  "in"  in  pred(...X...),  or  it  is  "out"  on 
the  rhs  of  this  clause  (again,  we  must  take  provisions  to  avoid  infinite  descend,  c.f.  (D)  in  "in"  algorithm).  In 
addition,  we  ignore  all  clauses  that  contain  an  explicit  fail  literal  among  their  rhs  literals. 
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(L')    An  argumeni  X  in  prcd(...X...)  on  the  Ihs  of  a  clause  C  is  panially  "out"  if  it  is  bound  by  a  functional  expres- 
sion f(Zj,...2„),  where  some  of  Z  may  contain  unbound  variables. 

3.2.3.  Computing  generalized  minimal  sets  ol  essential  arguments 

The  collection  of  minimal  sets  of  esseniial  argumenus  (MSEA's)  a  predicate  may  have  depends,  obviously, 
upon  the  way  this  predicate  is  defined.  More  clearly,  if  there  are  several  alternative  ways  of  defining  a  given  predi- 
cate (assuming  that  these  definitions  give  it  the  same  "meaning")  then  we  may  receive  possibly  different  collections 
of  MSEA's  each  time.  Still  more  to  the  point:  if  we  alter  the  ordering  of  the  rhs  literals  in  the  definition  of  a  predi- 
cate, we  may  also  change  its  set  of  MSEA's.  We  call  the  set  of  MSEA's  existing  for  a  current  definition  of  a  predi- 
cate the  set  of  active  MSEA's  for  this  predicate.  When  we  reverse  the  predicate  wc  want  a  specific  MSEA  to  be 
among  its  active  MSEA's.  If  this  is  not  already  the  ca^e,  then  we  have  to  alter  the  definition  of  this  predicate  to 
make  the  said  MSEA  an  active  one.  As  an  example  take  the  following  clause  from  our  Prolog  parser; 

objectbe(01,02J>l,P2J'SA,P)  :- 
venpass(01,02,Pl,P3), 
@([P2,P3],PSA,P). 

Assuming  that  (01}  and  {P31  are  MSEA's  of  venpass  and  iliat  P3  is  "out"  in  venpass  whenever  01  is  "in",  we 
obtain  thai  (01)  is  the  only  active  MSEA  of  objectbe.  Ho\\e\er,  if  we  reverse  the  order  of  venpass  and  @,  then  (P) 
becomes  the  new  active  MSEA,  while  (01 }  is  no  longer  acme. 

Consider  the  following  abstract  clause  defining  predicate  R  : 

R(X,,...,X_j:-Q,(...),Q,(...) Q_^(...).  (DD 

Suppose  that,  as  defined  by  (Dl),  R_  has  the  set  MS  =(m|,...,m  |  of  MSEA's.  Wc  call  MS^  the  set  of  actjvc  MSEA's, 
as  opposed  to  the  set  MR  a  MS  of  all  MSEA  lor  R  thai  can  be  obtained  by  permuting  the  order  of  literals  on  the 
right-hand  side  of  Dl.  Let  us  assume  now  thai  R  occurs  on  rhs  of  some  other  clause,  as  shown  below: 

P(X,,...,X^) :-  R,(X,  ,,...,X,_^, ),  R^(X^ , X^j^.), ...,  R^(X^  ,,...,X  ^^^).  (CI) 

We  want  to  compute  MS,  the  set  of  active  MSEA's  for  P,  as  defined  by  (CI),  where  s  >  0,  assuming  that  we  know 
the  sets  of  active  MSEA  for  each  R  on  the  rhs."'  If  s=0,  thai  is  P  has  no  rhs  in  its  definition,  then  if  P(X, X  )  is  a 

1  ^     1  n 

cal]  to  P  on  the  rhs  of  some  clause  and  X*  is  a  subset  of  (X,,...,X  1  then  X'  is  a  MSEA  in  P  if  X'  is  the  smallest  set 

^       1  n  ^ 

such  that  all  arguments  in  X'  consistently  unity  w  iih  tlie  corresponding  arguments  in  at  most  1  occurrence  of  P  on 
the  Ihs  anywhere  in  the  program.  *  In  one  special  case,  if  tliere  is  only  one  assertion  P(X  X^)  in  the  entire  pro- 
grain  and  every  (X^)  is  a  MSEA,  then  P's  set  of  MSEA's  can  be  replaced  by  the  set  containing  only  one  element: 
the  empty  set,  i.e.,  by  (0).  For  example,  the  lexicon  lookup  predicate  vrb(Vl,V2,Num,P)  has  two  sets  of  essential 
arguments:  {VI )  and  (Num.P).  This  is  because  ihe.sc  are  minimal  sets  such  that  whenever  we  bind  all  arguments  in 
either  of  them  the  resulting  instantiation  of  vrb  can  be  unified  with  at  most  one  assertion  in  the  lexicon,  which  con- 
sists, among  others,  of  the  following  clauses: 

vrb([lookslV],V,sg,look). 
vrb([looklV],V,pl,look). 
vrb([arriveslV],V,sg,arrive). 
vrb([arrivelV],V,pl,arrive). 

When  s  >  1,  that  is,  P  has  at  least  one  literal  on  the  rhs,  we  use  the  recursive  procedure  MSEAS  to  compute 
the  set  of  MSEA's  for  P,  providing  that  we  already  know  the  set  of  MSEA's  for  each  literal  occurring  on  the  rhs. 
Before  presenting  the  procedure,  we  introduce  two  auxiliary  concepts.  Let  T  be  a  set  of  terms,  that  is,  variables  and 
functional    expressions,    then    'VAR(T)    is    the    set    of   all    variables    occurring    in    the    terms    of   T.    Thus 

MSEA's  of  basic  predicates,  such  as  concai,  arc  assumed  to  be  known  apiion;  .MSEA's  for  recursive  predicates  are  first  computed  from 
non-recursive  clauses. 

The  al  most  1  requirement  is  the  strictest  possible,  and  ii  can  be  relaxed  to  at  most  n  in  specific  applications.  The  choice  of  n  may  depend 
upon  the  nature  of  the  input  language  being  processed  (it  ma>  be  n-dcgree  ambiguous),  and/or  the  cost  of  backing  up  from  unsuccessful  calls. 


VAR((f(X),Y,g(c,f(Z),X)))  =  {X,YZ).  Wc  assume  thai  symbols  X^  in  definitions  (CI)  and  (Dl)  above  represent 
terms,  not  just  variables.  For  the  purpose  of  this  algorithm  we  also  introduce  the  directed  relation  is  always  unifiable 
with  between  argument  terms,  and  define  it  as  follows.  An  argument  Y  is  always  unifiable  with  an  argument  X  if 
ihey  unify  regardless  of  the  possible  bindings  of  any  variables  occurring  in  Y  (after  standardizing  apart  any  unbound 
variables  remaining  in  them).  All  variables  occurring  in  X  are  unbound.  Thus,  any  term  is  always  unifiable  with  a 
variable;  a  functional  expression  f(A)  is  always  unifiable  with  a  functional  expression  f(B)  if  A  is  always  unifiable 
with  B;  a  constant  is  always  unifiable  with  identical  constant.  However,  a  variable  is  not  always  unifiable  with  a 
non-variable,  including  a  functional  expression.  To  see  it,  consider  the  variable  X  and  functional  term  f(Y):  X  is  not 
always  unifiable  with  f(Y)  because  if  we  substitute  g(Z)  for  X  then  the  so  obtained  terms  do  not  unify.  The  reason 
for  introducing  this  relation  will  be  explained  shortly. 

The  following  algorithm  is  suggested  for  computing  sets  of  active  MSEA's  in  P;  MSEAS(MS,MSEA,VP,i,OUT), 
where  i>l.  The  steps  (3)  and  (7)  are  included  for  the  sU"onger  version  of  the  algorithm  that  can  properly  handle 
recursive  clauses. 

(1)  Start  with  MSEA  =  0,  VP  =  VAR((X|,...,XJ),  i=l,  and  OUT=OUTq  =  0.  When  the  computation  is  com- 
pleted, MS  is  bound  to  the  set  of  active  MSEA's  for  P. 

(2)  Let  MRj  be  the  set  of  active  MSEA's  of  R^,  and  let  MRUj  be  obtained  from  MR^  by  replacing  all  variables 
in  each  member  of  MR   by  their  corresp()nding  actual  arguments  of  Rj  on  the  rhs  of  (CI). 

(3)  Strong  version  only:  U  R,=P  then  for  every  ni,  ^  e  MRUj  if  every  argument  Y^  6  nij  ^^  is  always  unifiable 
with  its  corresponding  argument  X^  in  P  then  remo\c  m     from  MRUj. 

(4)  Foreachmj  €  MRU,  (j  =  l,...,r)  the  set  |ij  =  (VAR(m, ,)- OUT^,)  n  VP  is  a  subset  of  an  active  MSEA  for 
P  but  only  if  0(u,  )  holds,  where  <)(M,  )  =  ln,  *  0  or  (u,  =  0  and  VAR(m,  )  =  0)].  Let  MP,  =  (u,  ,  I 
(t)(|i    ),  j=I,...j),  where  r  >  0.  If  MP  =  0  then  (CI )  is  ill-formed  and  cannot  be  executed. 

(5)  For  each  Hj  e  MP,  we  do  the  lollowing:  (a)  assume  that  (i,  is  "in"  in  R,;  (b)  compute  set  OUT  of  "out" 
arguments  for  R,;  (c)  compute  OUT,  ;=  OUT  <j  OUT^;  (d)  recursively  call 
MSEAS(MS,j,^,^,VP,2,0UT,j);  (e)  assign  MS  :='u^|  ^  MS,^. 

(6)  In  some  i-th  step,  where  1  <  i  <  s,  and  MSEA=|i  ,  ^,  let's  suppose  that  MR^  and  MRU  are  the  sets  of  active 
MSEA's  and  their  instantiations  with  actual  aruumcnts  of  R  ,  for  the  literal  R  on  the  rhs  of  (CI). 

(7)  Strong  version  only:  If  R  =P  then  for  every  m  e  MRU  if  every  argument  Y^  £  m_^  is  always  unifiable 
With  its  corresponding  argument  X  in  P  then  remove  m     from  MRU  . 

(8)  Again,  we  compute  the  set  MP  =  (|i    I  i=l r  ),  where  |i    =  (VAR(m  )  -  OUT      ),  where  OUT       is  the 


'■J 


set  of  all  "out"  arguments  in  literals  R,  to  R^ 


ij     ^        ^   i.y  i-\y'  '-u 


(9)  For  every  m  ,  m  ,  e  MRU  ,  if  m  ,  m  ,  are  obtained  from  the  MSEA's  for  R  that  are  active  at  the  same 
time  (i.e.,  belong  to  the  set  of  active  MSEA's  for  the  same  definition  of  R  ),  and  such  that  n_  c  |i  j^,  then 
eliminate  |i  from  MP .  (When  we  compute  active  MSEA's  only  as  we  do  here,  then  all  m^  are  active  at  the 
same  time;  but  see  below  for  a  possible  extension  to  this  algorithm.) 

(10)  For  each  n    remaining  in  MP   where  i  <s  do  the  following: 

(a)  if  |J.    =0  then:  (i)  compute  set  OUT  of  "out"  arguments  of  R  ;  (ii)  compute  OUT    :=  OUT  u  OUT  jj^; 

(ni)  call  MSEAS(MS^  ,H_,j^,VP,i+ LOUT  ^); 

(b)  otherwise,  if  |i    ^  0  and  |i    c  VP  then:  (i)  assume  v  =  )j.    n  VP  is  "in";  (ii)  compute  OUT  of  "out" 

arguments       of      R_;       (iii)       compute       OUT         :=       OUT       u       OUT_  ,^;       (iv)       call 
MSEAS(MS_  ,n__,j,uv,VP,i-(-LOUT^); 

(c)  otherwise  quit  returning  nil. 

(11)  Compute  MS  :=  ^  _,  ,  MS_  ; 

(12)  Fori=s-i-l,i.e.,forMSEAS(MS,MSEA,VP,s-(-l,OUT),doMS:=  (MSEA). 

The  weak  version  of  this  algorithm,  that  is,  with  steps  (3)  and  (7)  removed,  is  sufficient  in  a  great  majority  of  cases, 
but  it  cannot  properly  handle  certain  types  of  recursive  definitions.  Consider,  for  example,  the  problem  of  assigning 


the  set  of  MSEA's  to  mem(Elem,Lisi),  where  mem  (list  membership)  is  defined  as  follows: 

mem(X,[XIL]). 
mem(X,[YIL]):-mem(X,L). 

The  weak  version  of  MSEAS  assigns  MS=(0),  which  means  that  mem  can  be  evaluated  successfully  at  any  lime. 
This  is  true,  but  impractical  smce  there  are  infinite  number  of  lists  of  which  a  certain  element  is  a  member.  The 
strong  version  of  MSEAS  eliminates  (Elem)  as  a  possible  MSEA  because  the  X  in  mem  on  the  rhs  is  always 
unifiable  with  the  X  in  mem  on  the  Ihs  of  the  recursive  second  clause.  This  leaves  us  with  only  one  MSEA,  which  is 
(List). 

The  algorithm  presented  here  can  also  be  used  to  compute  the  set  of  all  MSEA's  for  P  by  repealing  all  the 
steps  for  every  permutation  of  literals  on  ihc  rhs  of  (CI)  and  every  combination  of  acuve  MSEA's  for  R^'s.  It  can 
also  be  modified  te  do  so  by  taking  MR^  lo  be  the  set  of  all  MSEA's  for  R^  and  repeating  all  the  steps  of  the  algo- 
rithm for  all  permutations  of  R^'s  on  the  rhs  of  (CI).  To  obtain  a  meaningful  result,  MSEA's  in  MR^'s  must  be 
grouped  into  sets  of  these  which  are  active  ai  the  same  time,  i.e.,  they  belong  to  the  set  of  active  MSEA's  for  a 
specific  definition  of  P.  MSEA's  belongmg  to  different  groups  give  ri.se  to  alternative  sets  of  MSEA's  in  the  final  set 
MS.  Note  that  in  this  modified  algorithm.  MS  becomes  a  set  of  scLs  of  sets. 

As  an  example,  we  compute  the  sei  of  all  MSEA's  lor  the  following  simple  clause.^  For  the  sake  of  simplicity 
we  assume  that  MSEA's  of  the  literals  on  itie  rhs  arc  known. 

quack(Al,A2,Pin,Pout)  :- 
np(Al,A2,Pfin), 

(a>(PinJ'out,Pfin). 

If  (AI)  is  the  only  active  MSEA  in  np,  and  Pfin  is  "out"  whenever  Al  is  "in",  then  (Al )  is  a  MSEA  in  quack.  This 
may  be  easily  seen  by  drawing  a  directed  arc  from  Al  to  Pfin  (indicating  "in"-"oul"  uansfer)  and  from  Pfin  in  np  to 
Pfin  in  @  (indicating  "out '-"in"  u-ansfcr).  Because  (Pfin)  is  an  active  MSEA  in  @*,  our  job  is  done.  On  the  other 
hand,  if  (Pfin)  were  the  only  active  MSEA  in  np,  then  the  resulting  MSEA  for  quack  would  be  { Al,Pin).  Next,  we 
reverse  the  order  of  np  and  @ ,  obtaining  the  following  new  definition  of  quack: 

quack(Al,A2,Pin,Pout)  :- 
@(Pin,Poul,Prm), 

np(Al,A2,Pfin). 

Following  the  same  steps  as  above  we  obtain  that  (Pin)  is  an  active  MSEA  in  quack,  assuming  that  (Pfin)  is  an 
active  MSEA  in  np.  If  ( AI )  were  the  only  active  MSEA  in  np,  as  before,  then  we  would  obtain  ( AI,Pin)  as  MSEA 
for  quack.  If  this  MSEA  proves  unacceptable  (because,  sa\,  Al  is  not  expected  to  be  bound  when  calling  quack) 
then  we  need  to  change  the  definition  of  np  so  thai  Pfin  becomes  its  active  MSEA.  Again  we  draw  directed  arcs 
from  Pin  to  Pfin  in  (£'  and  from  Pfin  in  (5  lo  Pfin  in  np.  We  may  note  here  that  since  Pout  is  not  essential,  quack  can- 
not be  reversed  to  compute  Al  out  of  Pout.  The  only  way  to  do  this  would  be  lo  change  the  definition  of  @  (list 
concatenation),  but  this  we  disallow  treating  (a  as  atomic  primitive.  The  same  result  can  be  obtained  using  the 
modified  version  of  the  algorithm  in  which  all  MSEA's  (active  or  not)  of  the  literals  on  tlie  rhs  of  a  clause  are  exam- 
ined at  the  same  time. 

Let  now  m  be  a  MSEA  of  P  such  thai  m  e  MP  -  MS,  i.e.,  m  is  not  an  active  MSEA,  where  MP  is  the  set  of  all 
MSEA's,  and  MS  is  the  set  of  all  acuve  MSEA's  for  P.  If  we  want  to  execute  P  successfully  with  only  the  argu- 
ments in  m  being  "in",  we  have  to  reorder  rhs  of  (CI)  so  that  m  becomes  an  active  MSEA.  If  m  is  a  non-active 
MSEA  then  we  may  actually  be  able  to  accomplish  this;  otherwise  it  is  impossible  without  rewriting  the  program. 
Suppose  then,  as  we  did  above,  thai  m  is  a  MSEA  for  P,  though  it  isn't  active  at  the  moment.  Thus  we  reorder  the 
literals  on  the  rhs  of  (CI)  so  that  m  becomes  active,  bui,  unfortunately,  while  doing  so  we  had  to  place  R  in  such  a 


'This  example  was  suggested  by  Ralph  Gnshman 

'Concalenauon  (@)has  two  acuve  MSEA's,  here,  iPin)  and  [Pfin] 


10 


position  that  none  of  its  active  MSEA's  is  guaranteed  to  be  "in",  and  only  some  mr  e  MR  -  MS  is  so  guaranteed. 
Technically  then  such  a  reordering  of  (Cl)'s  rhs  is  not  admissible,  because  R  cannot  be  executed  successfully  with 
only  mr  being  "in".  In  this  situation  we  may  decide  to  replace  the  current  definition  of  R  ,  which  is  (Dl  j,  by  a  new 
definiuon  (D2)  in  which  the  literals  on  the  rhs  of  (Dl )  are  reordered  so  that  mr  becomes  active.  Basically,  there  are 
two  ways  to  approach  the  problem  of  goal  reordering  on  the  right-hand  side  of  P: 

(1)  Place  R^  on  the  rhs  as  soon  as  one  of  its  active  MSEA's  is  guaranteed  to  be  "in";  otherwise  wait  and  place 
other  literals  ahead  (if  possible).  Change  definition  of  R^  only  when  no  further  progress  is  possible. 

(2)  Place  R_  on  the  rhs  as  soon  as  any  of  its  MSEA's  (active  or  not)  is  "in".  Change  definition  of  R_  accordingly. 

What  happens,  however,  if  R  is  on  the  rhs  of  a  dcfmition  of  some  other  predicate  PI?  If  we  alter  the  definition  of  R_ 
10  make  the  new  definition  of  P  admissil  'c,  v.c  ma\  end  up  with  having  to  change  it  again  to  have  both  P  and  PI 
admissible.  In  other  words,  if  MR  is  the  ,ci  of  MSEA  for  R  that  Guarantees  admussibiliiv  of  P  (as  far  as  R  is  con- 
cemed),  and  MR  is  the  set  of  MSEA  for  R  thai  v.  ould  make  PI  admissible  then  we  have  to  change  the  definiuon  of 
R  so  that  at  least  one  MSEA  in  MR  n  MR  becomes  active.  This  can  get  further  complicated  by  possible  changes 
to  the  definitions  of  other  predicate^  on  the  rhs  of  P  and  PI.  The  best  way  to  avoid  such  complications  is  to  limit  the 
changes  to  the  definition  of  PI  itself,  and  also  assume  that  certain  primitive  predicates  (such  as  concat,  member, 
cons,  etc.)  are  not  subject  to  re -definition  and  must  be  considered  atomic. 

3.2.4.  A  detailed  example 

Before  we  proceed,  let  us  analyse  in  detail  the  process  of  computing  the  set  of  MSEA's  for  a  simple  recursive 
literal.  Let's  assume  the  literal  vp  is  defined  as  follows: 

[1]  vp(Vl,V3,Args,Vsem) :-  vp(Vl,V2,[CsemlArgs],Vsem),np(V2,V3,Csem). 
[2]  vp(Vl,V2,Args,Vsem)  :-  v(Vl,V2,Args.VscmV 
[3]  v([loveslX],X.[Obj,Subj],love(Subi,Ohjj). 
[4]  np([marylX],X,maryj. 

For  the  sake  of  simplicity,  we  assume  that  MSEA's  of  v  and  np  are  already  known  and  are  [{Vl,Args),{Vsem)) 
and  ( (V2),(Csem) ),  respectively.  In  other  words,  both  literals  have  two  alternative  sets  of  MSEA.  We  include 
Args  among  the  essential  arguments  of  v,  even  if  it  may  not  be  required  especially  when  each  verb  is  assumed  to 
translate  into  a  single,  unique  predicate.^  We  proceed  to  compute  the  set  of  MSEA's  for  vp  in  [1]  using  first  the 
weak  version  of  the  procedure  MSEAS  described  in  the  previous  section,  i.e.,  leaving  out  steps  (3)  and  (7).  The  first 
step  is  to  create  the  set  VP  of  variables  of  the  head  literal.  We  obtain  VP=(Vl,V3,Args,Vsem).  Next,  we  have  to 
compute  the  set  of  MSEA's  for  the  first  literal  on  the  right-hand  side,  which  happens  to  be  vp  as  well.  To  accom- 
plish this  we  use  the  second  clause  [2],  and  obtain  the  result  {{Vl,Args},(Vsem)).  This  is  because  in  [2]  vp 
rewrites  to  v  and  MSEA's  of  v  are  known.  From  here  we  obtain  that  MRU,=((Vl,Args),{Vsem)},  and  subse- 
quently that  |ij  J  =  (Vl,Args)  and  (ij .,  =  (Vsem).  They  both  satisfy  the  condition  (J),  and  thus  we  have  MP.v= 
{(Vl,Args),{Vsem)}.  The  next  step  is  to  call  the  procedure  recursively  for  each  element  of  MP^,  thus  creating 
alternative  branches  of  compulation.  Let's  concentrate  on  \i^  ^  first,  and  assume  its  elements  are  "in"  arguments  in  vp 
on  the  right-hand  side  of  [1].  We  proceed  to  compute  the  set  of  "out"  arguments  in  this  vp  literal,  assuming  that  VI 
and  Args  are  "in".  The  result  is  0UT,  =  [V2,Vsem),  which  follows  from  the  fact  that  vp  rewrites  to  v.  Since  OUTq 
is  empty,  we  obtain  OUTj  ^  =  OUTj  =  (V2,Vscm).  Now  we  call  MSEAS  recursively  with  its  second  parameter 
bound  by  { (Vl,Args} ).  Within  this  call,  the  above  steps  are  repeated  for  ihe  second  literal  on  the  rhs  of  [1],  which 
isnp.  MSEA's  for  np  give  rise  to  MRU,  =  ( [V2),(Cscm] ),  from  where  we  compute  MP^  =  {{),{Csem)).  We  take 
ji  =[}  as  the  set  of  "in"  arguments  in  np,  obtaining  OUT^  j=[V3,Csem).  After  one  more,  this  time  tnvial,  recur- 
sive call  to  MSEAS  we  obtain  MS=(  fVl.Args) ).  The  other  element  of  MP^  is  [i^^  =  (Csem)  but  this  one  is  not 
considered  because  (Csem)  is  not  a  subset  of  VP.  This  concludes  exploration  of  the  recursive  branch  below  |ij  ^. 
For  |ij  ,=  {Vsem)  we  assume  Vsem  to  be  "in"  and  compute  OUTj  ^  =  {VI, Csem, Args).  Here  VI  is  only  partially 
"out"  but  this  will  suffice.  Csem  and  Args  are  full)  "out"  since  we  know  Vsem,  and  vp  rewrites  to  v  where  the  third 


'  Some  verbs  can  be  boih  iransiuve  and  iniransilivc  depending  upon  use.    For  example,  read  can  lake  either  one  argument,  as  in  John 
reads,  or  two  arguments,  as  in  John  reads  a  book. 
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argument  is  always  "om"  whenever  ihc  lasi  argument  is  "in".  Thus,  we  obtain  M?^=[  ( V2),( ) ).  The  first  element  of 
this  set  is  not  a  subset  of  VP,  and  thus  is  not  taken  under  consideration.  The  other  yields  MS=[{Vsem))  in  the  next 
call  to  MSEAS.  In  the  end  we  obtain  two  akcmaiive  scLs  of  MSEA  for  vp:  (Vl.Args)  and  (Vsem).  This  indicates 
that  vp  could,  in  principle,  be  run  in  two  directions:  with  VI  and  Args  known,  or  else  with  Vsem  known.  The  predi- 
cate is  thus  reversible  even  without  changing  ius  definition.  This  result  is  based  on  the  assumption  that  the  recursion 
in  clause  [1]  will  not  go  forever,  and  that  tlie  slop  condition  in  [2]  will  be  used  successfully.  The  reader  may  note 
that  this  assumption  is  not  valid  for  the  code  consisting  of  clauses  [1  ]  to  [4]  but  it  could  be  achieved  by  normalizing 
the  program  as  discussed  in  section  4.  The  fact  that  this  program  is  actually  ill-formed  as  it  stands  falls  out  neatly  if 
we  use  the  stronger  version  of  the  MSEAS  procedure,  i.e.,  we  replace  back  the  steps  (3)  and  (7).  Both  MSEA's 
(Vl.Args)  and  (Vsem)  obtained  form  the  non-recursive  clause  for  vp  are  eliminated  in  the  analysis  of  the  recursive 
clause  because  VI  and  Vsem  are  passed  unchanged  from  the  left  to  the  right  side,  and  Args  rewrites  into  a  func- 
tional expression  which  is  always  unifiable  v^iih  it.  We  obtain  M  '^  =  0  in  step  (4),  and  thus  that  the  recursive  clause 
is  ill-formed. 

At  the  end  it  may  be  useful  to  note  that  in  the  example  analysed  here  we  knew  the  set  of  MSEA's  for  vp  from 
clause  [2],  from  the  weak  version  of  MSEAS,  e\en  before  considering  the  recursive  rule  in  [1].  This  will  not  always 
be  the  case,  and  the  set  obtained  from  non-recursive  rules  could  be  narrowed  to  a  smaller  set  of  MSEA's. '°  To  see 
that  consider  a  modification  of  clause  |1],  where  variable  Csem  is  replaced  by  some  new  variable  Xsem  that  does 
not  occur  in  np.  Since  now  Csem  would  not  bo  "out"  aficr  vp  returns  in  [  1  ].  (i., ,  would  not  be  empty  but  would  con- 
tain Csem,  which  is  not  in  VP  Thi.s  would  luI  oil  ihc  ciuirc  branch  under  \i^ .,.  and  thus  MSEAS  (the  weak  version) 
would  return  only  one  possible  MSEA  for  vp,  liiai  is  (Xl.Args). 

3.2.5.  Reordering  literals  on  clause's  rhs 

When  attempting  to  expand  a  literal  on  the  rhs  of  any  clause  the  following  basic  rule  should  be  observed: 
never  expand  a  literal  before  at  least  one  its  MSE.A's  is  "in",  which  means  that  all  arguments  in  at  least  one  MSEA 
are  bound.  If  the  "in"  MSEA  is  not  active  then  recursivcl>  reorder  the  rhs  of  the  definition  of  the  predicate  in  ques- 
tion. The  following  algorithm  uses  this  simple  principle  to  reorder  rhs  of  parser  clauses  for  reversed  use  in  genera- 
lion.  This  algorithm  uses  the  information  aboul  "in"  and  "out"  arguments  as  computed  by  the  algorithm  given  in  the 
section  above. 

Reordering  rhs  of  a  clause:  head  :-  old-rhs. 

REORDER("head  :-  old-rhs","hcad  :-  new-rhs"); 
begin 

new-rhs:=  0; 

compute  and  mark  "in"  arguments  in  head; 
repeat  until  old-rhs  =0 
begin 

mark  as  "in"  those  arguments  in  old-rhs  which  are  either 
marked  "in"  in  head,  or 
marked  "in"  or  "out"  in  new-rhs,  or 
constants; 
find  the  left-most  literal  L  in  old-rhs  such  that 

it  has  an  "in"  MSEA; 
if  no  such  literal  found  then  quit("not  reversible"); 
compute  and  mark  "in"  and  "out"  arguments  in  L; 
new-rhs  :=  APPEND-AT-THE-END(new-rhs,L); 
old-rhs  ;=  REMOVE(okl-rhs,L); 
end; 
mark  as  "out"  those  arguments  in  head  that  are  marked  "out"  in  new-rhs 
end; 


An  empty  sei  of  MSEA  indicates  an  ill-formed  clause 
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As  discussed  in  ihe  previous  section  this  simple  algorithm  can  be  generalized  to  include  complicated  re-definition  of 
predicates  of  certain  literals  so  thai  ihcy  can  be  scheduled  even  if  none  of  its  currently  active  MSEA's  is  "in".  In 
practice,  wc  proceed  top-down  altering  definitions  of  predicates  of  the  literals  to  make  their  MSEA's  active  as 
necessary.  When  reversing  our  parser,  we  start  with  the  top  level  predicate  parse(S,P)  assuming  that  its  only  active 
MSEA  to  be  (P),  where  P  is  bound  to  the  regularized  parse  structure  of  a  sentence.  We  explicitly  identify  and  mark 
P  as  "in"  and  add  the  requirement  that  S  must  be  marked  "out"  upon  completion  of  rhs  reordenng.  This  last  condi- 
tion is  necessary  if  the  reversed  program  is  to  retain  its  intended  meaningfulness,  that  is,  to  produce  the  expected 
output.  We  proceed  to  adjust  the  definition  of  parse  (which  is  originally  written  with  (S)  as  the  active  MSEA)  to 
reflect  that  now  (P)  is  active.  We  continue  until  wc  reach  the  level  of  atomic  or  non-reversible  primitives  such  as 
concat,  member,  or  dictionary  look-up  routines.  If  this  lop-down  process  succeeds  at  reversing  predicate  definitions 
at  each  level  down  to  the  primitives,  and  the  primitives  need  no  re-dcfinition,  then  the  process  is  successful,  and  the 
reversed-parser  generator  is  obtained. 

The  revised  version  of  REORDER  is  given  below  as  INVERSE(clause,ins,outs),  where  clause  is  in  the  form 
head  :-  old-rhs,  ins  is  the  set  of  these  arguments  in  VAR(head)  that  are  known  to  be  "in",  while  out5  are  tho.se  argu- 
ments in  VAR(head)  that  are  required  to  be  "out"  after  the  clause  is  executed. 

Inverting  the  Prolog  program  with  the  top-lcvcl  clause  head  :-  old-rhs. 

INVERSE(,"head  :-  old-rhs", ins,ouLs): 
begin 

compute  M  the  set  of  all  MSEA's  for  head; 
for  every  MSEA  m  6  M  do 
begin 

OUT  :=  0; 

if  m  is  an  active  MSEA  such  that  mcins  then 

begin 

compute  and  mark  "out"  argumenLs  in  head;  add  them  to  OUT; 
if  outscOUT  then  DONE("head:-old-rhs") 
end 

else  if  m  is  a  non-activc  MSEA  such  that  mcins  then 
begin 

new-rhs  :=  0;  old-rhs- 1  :=  old-rhs;  QUIT  :=  false; 
for  every  literal  L  in  the  program  do  M^  :=  0; 
(this  is  done  only  once  during  the  inversion  process) 
repeat 

mark  as  "in"  those  arguments  in  old-rhs-1  which  are  either 

constants,  or  marked  "in"  in  head,  or  y_ 

marked  "in"  or  "out"  in  new-rhs; 
LL:  find  the  left-most  literal  L  in  old-rhs- 1  such  that  it  has  an  "in"  MSEA  m^^; 
if  L  exists  then 
begin 

if  m^^  is  non-active  in  L  then 

if  Mj  =  0  or  m^^  e  Mj^  then 
begin 


M|  :=  M^^  u  ("^l'' 
for  every  clause  "LI  :-  rhs^^,"  in  the  program 
such  that  LI  has  the  same  predicate  as  L  do 
INVERSE("L1  :-rhsL,",ML,0) 
end 

else  U'y  another  L  at  LL; 
compute  and  mark  "in"  and  "out"  arguments  in  L; 
add  "out"  arguments  to  OUT; 
new-rhs  :=  APPEND-AT-THE-END(new-rhs,L); 
old-rhs-1  :=  REMOVE(old-rhs-l,L) 
end  (if) 
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else  QUIT  :=  irue 
until  old-rhs-1  =  0  or  QUIT: 
if  oulscOUT  then  DONE("hcad:-new-rhs") 
end  (elseif) 
end;  (for) 

writeC'program  cannot  be  inverted  a.s  specified") 
end; 

The  reader  may  note  that  INVERSE  is  not  a  complete  program  yet,  and  it  needs  a  few  minor  adjustments  before  it 
can  be  safely  used.  For  one  thmg,  we  have  to  make  sure  that  the  recursive  calls  do  not  create  an  infinite  loop.  This 
may  happen  if  the  literal  selected  for  recursive  inversion  on  the  right-hand  side  of  the  currently  open  clause  has  the 
predicate  which  is  identical  to  that  in  the  head  of  this  clause,  and  this  same  clause  is  again  selected  for  inversion.  In 
a  more  general  case  we  have  to  block  recursive  inversion  of  any  clause  which  is  being  currently  open  for  inversion 
by  the  chain  of  recursive  calls  to  INVERSE.  This  can  be  accomplished  by  keeping  a  list  of  all  clauses  opjn  for 
inversion  and  testing  its  membership  before  every  recursive  call  to  INVERSE.  Another  problem  is  that,  as  it  stands, 
INVERSE  cannot  truly  guarantee  that,  in  reaching  a  particular  ordering  of  the  literals  on  the  right-hand  side  of  a 
clause,  it  will  accomodate  more  than  one  active  MSEA  at  a  lime.  What  it  docs  at  present  is  merely  to  make  sure  that 
an  inverted  literal  is  not  inverted  again.  On  the  other  hand,  making  a  literal  executable  in  more  than  one  directions  at 
the  same  lime,  rather  than,  what  INVERSE  doe^,  only  changing  its  direction  from  one  to  another,  creates  a  some- 
what differeni  problem,  which  may  not  be  relevant  in  the  present  context.  Nonetheless,  a  more  complete  algorithm 
that  would  include  tlie  above  provision  is  noi  difficult  to  obtain  and  we  leave  it  for  the  reader  as  an  exercise. 

3.2.6.  Essential  arguments  for  greater  et1icienc_\ 

Even  though  certain  arguments  in  a  literal  ma\'  not  be  strictly  essential,  in  the  sense  that  the  literal  v>ill  exe- 
cute successfully  without  them  being  bound,  the  efficiency  of  the  program  can  be  increased  if  these  arguments  are 
actually  "in"  before  the  said  literal  is  executed.  As  an  example,  we  may  consider  the  following  (hypothetical)  parser 
clause: 

yesnoq(Al,A4,P)  :- 

verb(Al,A2,Num,Gen,P2), 
subject(A2,A3,Num,Gen,PI  j, 
object(A3,A4,Pl,P2,P). 

When  rewriting  this  clause  for  generation,  wc  would  place  object  first  (it  has  P  "in",  and  A3,  PI,  P2  "out"),  but  then 
the  REORDER  algorithm  preserves  the  order  of  the  original  definition  if  more  than  one  literal  becomes  available  for 
scheduling  at  the  same  ume.  Thus  verb  would  be  scheduled  second  and  subject  last,  resulting  in  the  following  gen- 
erator clause: 

yesnoq(Al,A4,Pj  :- 

ohject(A3,A4,PlJ'2,P), 
verb(  A 1 .  A2,Num,Gen,P2 ), 
subject(A2,A3,Num,Gen,Pl ). 

Suppose  now  that  the  information  about  the  number  and  gender  agreement  of  the  pair  verb-subject  is  placed  in  the 
translation  PI  of  the  subject,  but  not  in  the  uanslation  P2  of  the  verb.  What  happens  is  that  when  we  call  verb  with 
P2  "in"  but  the  rest  of  its  arguments  unbound,  we  pick  up  a  random  lexical  form  of  P2  (which  contains  verb's  root 
form)  from  the  lexicon  and  later,  while  executing  subject,  we  u-y  to  match  it  against  the  number/gender  information 
contained  in  PI.  If  we  are  unlucky,  we  may  backup  several  times  before  these  values  coincide.  A  better  approach 
would  be  to  schedule  subject  first,  thus  .setting  Num  and  Gen  "in"  and  then  make  one  sure  call  to  verb.  What  we 
need  to  do  now  is  lo  guarantee  that  the  reordering  algorithm  gets  things  in  the  right  order!  This  could  be  easily 
achieved  if  we  make  Num  and  Gen  essential  in  verb  together  with  P2.  In  other  words,  we  want  the  set  of  MSEA's 
for  verb  to  be  {{Al),{Num,Gen,P2) ),  which  is  quite  understandable,  as  Num,  Gen  and  P2  (the  root  form  of  the 
verb)  fully  define  the  verb's  lexical  form.  When  verb  is  called  with  Al  and  either  Num  or  Gen  unbound,  the 
number  of  different  lexical  verb  forms  thai  can  be  matched  in  the  lexicon  is  almost  always  greater  than  one,  and  we 
may  have  to  make  a  guess.  This  considerauon  alone  can  be  a  sufficient  criterion  to  make  Num  and  Gen  essential. 
Adding  Num  and  Gen  to  the  MSEA  for  verb  results  in  the  following  generator  clause: 

yesnoq(Al,A4,P)  :- 

object(A3,A4,PI,P2,P), 
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subject(A2,A3JMum,Gen,Pl), 
verb(A  1 ,  A2,Num  .Gen,P2). 

The  method  can  also  be  used  to  determine  other  essential  arguments  of  lexicon  look-up  primitives,  and  other  fact 
clauses.  Thus,  noun(NlJs'2,Num,P)  has  (Nl]  and  (?)  as  MSEA's  simply  because  these  are  only  arguments  that  can 
reduce  number  of  possible  matches  in  the  lexicon  from  a  poieniialiy  large  number  to  1  (if  Nl  is  "in"),  or  to  2  (if  P  is 
"in").  If  we  add  Num  to  the  second  MSEA,  obtaining  (Num.P),  then,  here  too,  the  number  of  possible  matches  in 
the  lexicon  is  reduced  to  1. 

This  method  of  expanding  the  set  of  essential  arguments  can  be  used  to  achieve  a  marked  improvement  in  the 
performance  of  the  generator,  but  the  method  may  easily  run  into  u-ouble  if  the  parser  is  not  uniformly  designed.  For 
example,  if  the  translation  PI  of  subject  contains  information  about  its  gender  only  and  the  translauon  of  verb  con- 
tains information  about  the  number  only,  then  extending  sets  of  essential  irgumc  iits  of  subject  to  [Num,Pl )  and  of 
verb  to  (Gen ^2)  would  result,  we  might  imagine,  in  a  deadlock  situation  in  which  both  wait  for  each  other  forever. 
INVERSE  will  not  deadlock,  but  it  will  refuse  to  reverse  such  a  program.  However,  it  may  sometimes  be  more 
desirable  to  detect  and  break  such  poicniial  deadlocks  rather  than  just  quit.  This  effect  may  be  achieved  by  making 
Num  and  Gen  second-class  essential  arguments,  and  thus  allowing  for  INVERSE  to  override  their  status  if  it  cannot 
reorder  a  clause  otherwise.  In  such  situations  we  may  be  confronted  with  ihe  problem  of  choosing  lesser  of  two 
evils.  Which  way  do  we  fare  better:  by  executing  subject  first,  or  by  executing  verb  first?  The  answer  seems  to 
depend  on  the  number  of  guesses  each  of  thciii  v, ould  hme  to  make,  and  favoring  the  one  which  makes  fewer 
guesses.  On  the  other  hand,  this  decision  must  also  depend  on  hox\'  much  compuiauon  has  to  be  undone  and  redone 
in  case  we  make  a  wrong  guess;  in  other  words  we  have  to  calculate  the  average  (or  worst)  amount  of  computation 
(and  time)  wasted  in  each  case.  This,  however,  ma\  not  be  easy  to  determine.  An  obvious  alternative  solution  to  the 
problem  of  deadlocked  goals,  apart  from  their  concurrent  evaluation,  is  to  normalize  the  grammar  so  thai  the 
deadlock-prone  clauses  are  eliminated,  or  al  least  their  number  minimized.  We  return  to  this  problem  in  section  4. 

3.3.  An  example  of  inverting  a  literal 

In  this  section  we  go  step  by  step  through  the  process  of  literal  inversion.  Let's  consider  the  following  parser 
clause": 

assertion(Al,A41,WHQ,P)  :- 
sa(Al,All.PAl). 
subject(All,A2,WHQ,Num,Pl), 
sa(A2,A21,PA2), 
verb(A21  ,A3,Sts.Num,P2), 
sas(A3,A31,Sts,PA3), 
object(A3 1  ,A4,0,Sts,asseri,Pl  .P2,PS  A,P), 
sao(A4,A41,OJ'A4), 
#([PA1,PA2J'A3,PA4],PSA). 

When  used  for  parsing,  Al  and  WHQ  are  "in"  while  A41  and  P  are  "out"  in  the  Ihs  literal  assertion.  On  the  rhs, 
object  literal,  for  example,  has  A31,  Sts,  assert,  PI  and  P2  "in",  and  A4,  O  and  P  "oul".'^  PSA  is  neither  "in"  nor 
"out".  When  the  clause  is  used  for  generation,  then  P  is  "in"  and  Al  is  "out".  In  object  literal  we  have  P  and  assert 
"in",  and  A31, 0,  PI,  P2  and  PSA  "out".  A4  and  Sts  are  neither  "in"  no;  "out". 

We  call  INVERSE  with  the  above  clause  as  the  value  of  the  first  parameter,  and  ins={P),  and  outs={Al). 
The  set  of  MSEA's  for  the  head  literal  a^.fcniOA!  is  ((A1),[P)).  As  it  stands,  (Al)  is  an  active  MSEA  m  assertion, 
while  (P)  is  not.  We  need  to  invert  assertion  so  that  (P)  becomes  active  and  thus  guarantees  execution  of  assertion 
with  argument  P  "in".  Since  (Al)  is  not  a  subset  of  ins,  we  proceed  to  consider  the  only  remaining,  non-active 
MSEA,  i.e.,  (P).  We  set  up  new-rhs=0,  old-rhs-l=old-rhs,  and  QUIT=false.  Next,  we  mark  "in"  arguments  in  old- 
rhs-1.  Since  new-rhs  is  empty,  we  look  for  those  which  are  marked  "in"  in  the  head  literal,  obtaining  P  in  object.  In 
addition,  the  fifth  argument  of  object  literal  is  a  constant.  Since  (P)  is  a  MSEA  for  object  (and  let's  assume  that  it  is 


"  For  the  sake  of  simplicily,  in  this,  and  in  ihe  following  examples,  we  may  occassionally  omil  some  of  the  argumenis  to  selected  literals, 
as  compared  wilh  the  code  given  in  appendices  A  and  B,  il"  ihcir  presence  is  noi  essenlial  lo  lUuslraie  ihe  problem  al  hand. 

''We  may  nole  here  Ihai  Pin  object  is  on))  paniall\  "out"  because  il  is  being  constructed  out  of  PI,  P2  and  PSA  while  the  latter  is  still  un- 
bound. However,  P  is  fuUy  "out"  in  assertion  because  PSA  is  "out"  in  #. 
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an  active  MSEA.  for  simplicity)  we  compuic  that  P  i>  "in"  and  A3 1,  O,  PI,  P2  and  PSA  are  "out"  in  object.  We  thus 
obtain  thatOUT=(A31,0,Pl,P2,PSA)  and  thai 

new-rhs  = 

object(A31,A4,0,Sts,assert,Pl,P:,PSA,P) 
oId-rhs-1  = 

sa(Al,All,PAl), 

subjeci{All,A2,WHQ,Num,Pl), 

sa(A2,A21,PA2), 

verb(A21,A3,Sts,Num,P2j, 

sas(A3,A31.SlsJ'A3), 

sao(A4,A41,OJ'A4), 

#([PA1,PA2,PA3,PA4],PSA) 

In  the  next  turn  of  the  repeat  loop,  we  mark  the  following  "in"  arguments  inold-rhs-1:  PI  in  subject,  P2  in  verb,  A31 
in  sas,  O  in  sao  and  PSA  in  #.  This  is  because  all  these  arguments  arc  now  "out"  in  new-rhs.  The  Iclt-most  literal 
with  an  "in"  MSEA  in  old-rhs-1  is  subject.  When  (PI)  is  "in",  ihcn  "out"  arguments  in  subject  arc  All  and  Num. 
We  add  ihem  lo  the  set  OUT,  obtaining  OUT  =  |  Al  l,A31,Num,0,Pl,P2,PSA).  Next,  we  modify  new-rhs  and  old- 
rhs-1  as  follows: 

new-rhs  = 

object(A?l,A4,0,Sts.assert,Pl,P:.PSA.P), 
subject(A  1 1  ,A2,WHQ,Num,Pl  j 
old-rhs-1  = 

sa(Al,All,PAl), 

sa(A2,A21,PA2), 

verb(A21,A3,Sts,Num,P2), 

sas(A3,A31,Sts.PA3), 

sao(A4,A41,0,PA4), 

#([PA  1  ,PA2,PA3  ,PA4  J  ,PS  A ) 

Now  the  "in"  arguments  in  old-rhs-1  arc:  Al  1  in  the  first  sa,  P2  and  Num  in  verb,  A31  in  sas,  O  in  sao  and  PSA  in  #. 
(P2,Num)  is  a  MSEA  for  verb  (again,  assume  it  is  active),  which  makes  A21  and  Sis  "out"  in  verb.  We  add  these 
two  to  OUT,  obtaining  OUT  =  {Al  l,A21,A31,Num.0,Pl,P2,PSA,Sts).  The  new  values  of  new-rhs  and  old-rhs-1 
are  as  follows: 

new-rhs  = 

object(A31,A4,0,Sts,as,scrt,Pl,P2,PSA,P), 

subjecl(A  1 1  ,A2,WHQ,Num,Pl ), 

verb(A21,A3,Sts,Num,P2) 
old-rhs-1  = 

sa(Al,All,PAl), 

sa(A2,A21,PA2), 

sas(A3,A31,Sts,PA3), 

sao(A4,A41,0,PA4), 

#([PA  1  ,PA2,PA3,PA4],PS  A) 

In  the  next  step  we'll  add  #  literal  at  the  end  of  new-rhs.  After  this,  PAl,  PA2,  PA3  and  PA4  will  become  marked 
"in"  in  old-rhs-1.  The  remaining  literals  in  old-rhs-1  are  moved  lo  new-rhs  in  the  same  fashion,  but  there  will  be  no 
more  changes  in  ordering.  The  final  effect  is  shown  below. 

assertion(Al,A41,WHQ,Pj  :- 

object(A31,A4,0,Sls,assert,Pl,P2,PSA,P), 

subject(Al  1  ,A2,WHQ,Num,Pl ), 

verb(A21,A3,Sis>IumJ>2j, 

#([PA1  ,PA2,PA3,PA4]  J'SA), 

sa(Al,All,PAl), 

sa(A2,A21,PA2), 

sas(A3,A31,StsJ'A3), 

sao(A4,A41,0,PA4), 
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4.  Expanding  the  applicability  ol  the  inversion  algorithm 

For  the  mosi  effective  use  of  ihc  inversion  algorithm,  the  original  PROLOG  program  of  the  parser  must  be  in  a 
certain  "normal"  form,  thai  is,  a  form  that  would  assure  program  inveriibiiiiy  and  produce  the  maximum  efficiency 
of  the  generator  program.  The  most  obvious  necessary  condition  that  a  program  must  satisfy  in  order  to  be  invertible 
by  INVERSE,  is  that  each  clause  in  this  program  must  be  invertible.  The  sufficient  condiuon  is  that  the  inverted 
clauses  taken  together  create  an  executable  whole.  Thus,  any  program  whose  inversion  involves  manipulating  of 
several  clauses  at  once  in  order  to  establish  some  global,  inter-clausal  ordering  of  literals,  is  not  in  the  "normal" 
form,  and  will  not  be  reversed  by  the  present  version  of  the  algorithm.  Nonetheless,  "non-normal"  programs  (or 
grammars)  do  exit,  and  can  be  quite  well-formed.  Moreover,  they  can  be  also  reversible,  though  this  may  involve 
somewhat  more  skill.  Understandably,  we  would  like  to  expand  the  applicability  of  our  inversion  algorithm  to 
cover  these  "non-normal"  cases  as  well.  One  way  to  achieve  this  end  is  to  construct  a  normalizer  that  would 
transform  the  non-normal  programs  into  normal  ones,  upon  which  INVERSE  could  be  run.  The  normalization  pro- 
cess would  replace  groups  of  clau.ses  in  the  onginal  program  by  semantically  equivalent  new  clauses  which  possess 
desired  properties,  that  is,  they  are  reversible  by  INVERSE.  This  operation  can  also  be  performed  at  the  level  of  the 
grammar,  so  that  groups  of  productions  arc  replaced  by  new  productions,  in  a  manner  somewhat  similar  to  that  of 
removing  left-recursion.  Of  course,  we  need  a  method  of  telling  a  "normal"  grammar  or  program  from  a  "non- 
normal"  one.  This  may  be  done  on  the  clause  by  clause  basis,  or  it  may  involve  larger  fragments  of  code,  but  the 
method  must  not  rely  on  criteria  which  require  the  normali/.cr  program  to  know  whether  a  given  clause  is  reversible 
or  not,  for  if  it  did,  we  would  have  to  attempt  to  reverse  this  clause  first,  before  normalization.  While  such  a  post- 
normalizer  is  not  entirely  out  of  place,  we  ore  probably  bcucr  off  if  we  expand  the  coverage  of  INVERSE  over  at 
least  these  "non-normal"  cases  which  cannot  be  normalized  bclorc  the  inversion  starts.  The  ultimate  goal  is  to 
describe  a  set  of  conditions  that  must  be  satislkd  in  designing  the  grammar  so  that  it  could  be  translated  into  an 
efficient  parser  or  generator  operatmg  under  a  .specific  evaluation  suategy  (a  top-down  interpretation  in  our  case).  If 
a  grammar  does  not  meet  these  criteria,  it  should  be  possible  to  "normalize"  it  using  an  automated  normalization. 
The  compiler/normalizer  would  provide  an  exua  degree  of  freedom  to  a  linguist  who  needs  not  necessarily  be  aware 
of  the  evaluation  requirements  for  the  parser  or  generator  based  on  his  grammar. 

In  this  section  we  discuss  only  a  lew  specific  cases  when  a  normalization  may  be  required,  each  of  them  being 
motivated  by  a  different  set  of  considerations.  We  sho\s  how  these  normalizations  apply  to  the  PROLOG  code  and 
discuss  whether  they  could  be  made  a  part  of  the  normalizer  program,  or  whether  they  call  for  an  extension  to  the 
inversion  algorithm  itself.  In  the  latter  case,  we  also  suggest  how  this  extension  could  be  accomplished.  First,  we 
discuss  how  the  clauses  in  a  parser  program  can  be  "normalized"  to  assure  meaningful  inversion  by  INVERSE. 
Then  we  look  at  how  the  normalization  process  can  be  used  to  enhance  efficiency  of  the  inverted  program. 
Although  we  limit  our  discussion  to  the  actual  prolog  code,  it  will  be  also  applicable  to  more  abstract  rewriting 
systems,  such  as  DCG's. 

4.1.  Inverting  deadlock-prone  clauses 

The  inversion  algorithm,  as  realized  by  the  procedure  INVERSE,  requires  that  for  each  clause  in  the  parser 
code  we  can  find  a  definite  order  of  literals  on  its  right-hand  side  that  would  satisfy  the  requirements  of  running  this 
clause  in  the  reverse:  appropriate  minimal  sets  of  essential  arguments  (MSEA's)  are  bound  at  the  right  time.  How- 
ever, this  requirement  is  by  no  means  guaranteed  and  INVERSE  may  encounter  clauses  for  which  no  ordering  of  the 
literals  on  the  right-hand  side  would  be  possible.  It  may  happen,  of  course,  that  the  clause  itself  is  ill-formed  but  this 
is  not  the  only  situation.  It  may  be  that  two  or  more  literals  on  the  right-hand  side  of  a  clause  cannot  be  scheduled 
because  each  is  waiting  for  the  other  to  deliver  the  missing  bindings  to  some  essential  arguments.  As  discussed  pre- 
viously, we  can  sometimes  break  such  deadlocks  by  allowing  the  generator  to  make  a  limited  amount  of  guesswork. 
This  solution  does  not  appear  very  satisfactory,  though.  Fortunately,  much  of  the  need  for  the  crude  deadlock  break- 
ing can  be  removed  by  applying  a  normalizauon  to  the  grammar  that  would  replace  deadlock-prone  clauses  by 
equivalent  new  clauses  that  can  be  reordered  for  generation.  The  general  solution  to  this  normalization  problem  is 
still  under  investigation;  here,  we  illustrate  the  problem  and  a  possible  solution  using  one  specific  situation. 

Consider  the  following,  somewhat  abstract,  parser  clause: 
sent(P) :-  np(Num,Pers,Pl),vp(Num,Pers,Pl,P). 
where  string  variables  are  omitted  for  clarity,  and  PI  and  P  carry  the  translations  of  np  and  sent,  respectively.  Sup- 
pose that  PI  is  the  only  essential  argument  in  np,  and  that  Num  and  Pers  are  "out"  whenever  PI  is  "in".  In  vp,  the 
essential  arguments  are  {P,Num,Pers)  and  PI  is  "out".  Obviously,  this  clause  cannot  be  inverted  for  generation, 
since  in  order  to  fire  vp  we  need  to  know  the  bindings  to  Num  and  Pers,  in  addition  to  P  (which  is  passed  from  sent). 
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These  we  could  get  by  finng  np,  but  we  cannot  do  this  either  since  we  need  to  know  the  binding  lo  PI ,  which  is  una- 
vailable until  vp  is  exe<;uted.  A  deadlock.  Suppose,  however,  that  vp  has  the  following  expansion: 

vp(NumJ'ers,Pl,f(Pl,P2,P3)j :-  verb(Num,Pcrs,P2),compl(P3). 

or,  perhaps, 

vpCNumPersJ"!,?);- verb(Num,Pcrs,P2j,compl(P3j,combinc([PlJ>2J'3],P). 

As  we  can  see,  the  critical  information  required  to  fire  np  literal  in  the  sent  clause,  that  is,  the  binding  to  PI,  can  be 
obtained  only  after  a  partial  evaluauon  of  vp,  and  before  the  bindings  for  Num  and  Pers  become  indispensable. 
Therefore,  even  though  (P.NumPersI  create  a  MSEA  for  vp,  the  bindings  to  the  last  two  are  not  used  until  the 
literal  verb(NumPers,P2)  is  called.  Indeed,  after  reordering  vp  for  generation  v.e  obtain  the  following  clause: 

vp(NumJ'ersJ'l,P):-combinc(|Pl.P2,P3],P),vcrb(Num,Pers,P2),compl(P3). 

Now  w  can  sec  in  which  order  the  literals  should  be  evaluated  to  avoid  the  deadlock.  We  need  to  evaluate 
combine([Pl,P2J'3]J')  first,  then  np(Num,Pers,Pl),  then  vcrb(.Num,PersJ'2),  and  finally  compl(P3).  One  way  to 
achieve  this  serialization  is  to  combine  both  clauses  into  a  single  new  clause  replacing  vp  literal  in  the  sent  clause  by 
the  right-hand  side  of  the  vp  clause,  and  propagating  all  unifications  between  variables  as  necessary.  So  obtained 
new  clause  is  subsequently  inverted  in  the  usual  fashion.  The  net  effect  is  as  follows: 

sentrP):-combine([Pl,P2,P3],P).np(Num,Pcrs,Pl),verb(Num,Pers,P2),compl(P3). 

The  same  effect  can  be  achieved  for  the  lirsi  version  of  the  vp  clause  above  by  "lifting"'-'  the  translation  pattern 
f(Pl,P2,P3)  from  vp  to  sent,  obtaining  the  following  clause: 

sent(f(Pl,P2,P3)) :-  np(Num,Pers,Pl  ),vcrb(Num,Pers.P2).compl(P3). 

or,  more  conservatively, 

sent(f(Pl,P2J'3))  :-  np(Num,Pers,Pl),vpUNum,Pers,P2,P3j. 
vp](Num,Pers,P2,P3) :-  verb(Num,Pers,P2),compl(P3). 

There  are  basically  two  ways  of  implementing  this  kind  of  inter-clausal  literal  reordering.  One  is  to  make  it  a  part  of 
the  "grammar  normalization"  process  and  thus  leaving  the  INVERSE  procedure  intact.  The  advantage  of  this  solu- 
tion IS  that  the  inversion  algorithm  will  reiain  its  relative  simplicity  and  elegance.  The  problem  is  that  it  may  be 
difficult  to  single  out  the  clauses  thai  should  be  considered  lor  this  transformation  without  actually  attempting  to 
reorder  their  literals  in  the  first  place.  This  Icaus  us  to  the  .second  alternative  implementation  which  involves 
modifications  to  INVERSE  itself.  The  new  INVERSE  would  not  limit  its  operation  to  single  clauses.  Instead,  upon 
failing  to  find  an  acceptable  ordering  for  the  literals  in  a  clause,  it  would  look  at  the  clauses  whose  heads  are 
involved  in  the  current  deadlock,  and  expand  the  reordenng  process  to  their  right-hand  sizes  also.  In  other  words, 
we  will  create  a  new  clause  for  each  possible  expansion  of  the  literal  in  question.  If  the  expanded  reordering  eventu- 
ally yields  an  executable  sequence,  appropriate  clauses  will  be  created  and  used  to  replace  those  in  the  parser.  If,  on 
the  other  hand,  the  expansion  brings  no  solution  (we  may  hit  the  lexicon  assertions)  then  we  may  have  no  choice  but 
to  allow  some  guesswork  to  be  performed  by  the  generator.  However,  in  this  latter  case  there  isn't  probably  much 
we  can  do  anyway,  because  this  would  mean  that  the  generator  docs  not  have  enough  information  to  make  deter- 
ministic selections  at  all.  A  word  of  caution  must  be  added  here,  however.  While  expanding  a  literal  on  the  right- 
hand  side  of  a  clause  we  must  make  sure  thai  we  are  not  going  to  end  up  in  an  infinite  loop  that  might  be  created  by 
expanding  recursive  literals.  Thus  a  loop  checking  must  be  made  v/hile  expanding.  Another  problem  may  be 
created  by  the  presence  of  "ill-formed"  recursive  rules.  These  need  to  be  normalized  before  the  inversion  process 
starts,  as  discussed  in  the  following  subsection. 

4.2.  Normalizing  ill-rormed  recursive  literals 

Thus  far  we  have  tacitly  assumed  that  the  grammar  on  which  our  parser  is  based  is  written  in  such  a  way  that 
it  can  be  executed  (for  parsing)  by  a  top-down,  lefi-to-nght  interpreter,  such  as  the  one  used  by  prolog.  If  this  is 
not  the  case,  that  is,  if  the  grammar  requlre^  a  different  kind  of  interpreter,  then  the  question  of  invertibility  can  only 
be  related  to  this  panicular  type  of  interpreter.  If  we  want  to  use  the  inversion  algorithm  described  here  to  invert  a 
parser  written  for  an  interpreter  different  than  top-down  and  lefi-to-right,  we  need  to  convert  it  first  into  a  version 
that  can  be  executed  by  a  top-down  interpreter.  This  problem  is  not,  strictly  speaking,  of  our  present  concern. 

We  shall  have  some  more  lo  say  about  ihc  "Llling  '  iransformaiion  later. 
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nonetheless  we  outline  here  how  such  situations  can  be  dealt  with  within  the  present  framework. 

Consider,  for  example,  the  following  situation.'" 

[01]  sent(Vl,V3,Sem) :-  np(Vl,V:,S,scm),vp(V2,V3,[Ssem],Sem). 

[02]  vp(\'l,V3,Args,Vscm) :-  vp(Vl,V2,[CsemlArgs],Vscm),np(V2,V3,Csem). 

[03]  \'pO'l,V2,Args,Vsem)  :-  v(Vl,V2,Args,Vscm). 

[04]  v(Vl,V2,[Iobj,Obj,Subj],give(Subj,Obj,lobj)) :-  givc(Vl,V2). 

[05]  v(Vl,V2,[Obj,Subj],love(Subj,Obj)) :-  Iove(Vl,V2). 

[06]  v(V],V2,[Subj],arrive(Subi)  :-  arrjvc(Vl,V2). 

[07]  love([loveslX],Xj. 

[08]  love([lovedlX],X). 

[09]  give([giveslX],X). 

[10]give([gavelX],X). 

[11]  arrive([arriveslX],X). 

[12]  arrive([arrivedlX],Xj. 

[13]  np([marylX],X,mary). 

[14]  np([johnlX],X,johnj. 

[15]  np([appleslX],X,apples). 

The  right-hand  side  of  the  first  \p  clause  [02]  cannoi  be  executed  v>ith  the  re\ersed  order  of  literals,  since  Csem, 
being  an  essential  argument  m  np  is  unbound  until  \p  is  executed.  Howe\'er.  if  we  do  not  re\ersc  the  order  of  vp 
and  np  literals  in  [02],  then  an  infinite  descend  will  result  during  generation.''  This  problem  could  be  remedied  (or 
so  it  seems)  by  swapping  the  order  of  the  vp  clauses  in  the  pair  [02],  [03],  and  allowing  for  the  non-recursive  rule  to 
be  attempted  first.  Specifically,  we  replace  the  tv*o  vp  clauses  by  the  following  clauses  (in  this  order): 

[02']  vp(\'l,V2,Ajgs,Vsem)  :-  v(Vl,V2,Args,Vsem),'. 

[03']  vp(Vl,V3,Args,Vsem)  :-  vp(Vl.V2,[CsemlArgs],Vsem),np(V2,V3,Csem). 

These  clauses  will  not  be  further  changed  by  INVERSE. 

However,  this  simple  replacement  will  not  help  the  generator  to  avoid  an  infinite  descend  when  the  form  bind- 
ing Sem  does  not  correspond  to  any  sentence  recognizable  by  the  parser.  Instead  of  just  swapping  the  clauses,  we 
try  to  achieve  an  executable  order  of  literals  in  [02]  by  first  testing  whether  the  stop  condition,  that  is,  clause  [03],  is 
ever  likely  to  be  used,  and  fail  if  it  is  not.  In  order  to  achieve  this,  we  introduce  a  new  non-terminals  vpl,  and 
replace  clauses  [02]  and  [03]  by  [021],  [022].  and  [023]  as  shown  below: 

[021]  vp(Vl,V3,Args,Sem)  :-  v(Vl,V2.Arl,Sem),vpI(V2,V3,Arl,Args). 

[022]  vpl(Vl,Vl,Args,Args)  :-  1. 

[023]  vpl(Vl,V3,Arl,Args) :-  vpl(Vl,V2,Arl,[CsemlArgs]j,np(V2,V3,Csem). 

In  this  way,  the  recursive  rule  consisting  of  clauses  [022]  and  [023]  cannot  be  used  unless  the  semantic  form  Sem 
given  as  input  for  generation  is  unifiable  with  the  semantic  form  of  a  literal  which  guarantees  a  conuollcd  exit  froi};i 
the  recursion,  in  this  case  v.  Thus,  if  the  recursive  rule  is  well-formed  we  are  guaranteed  to  use  [022]  at  some  point, 
perhaps  after  a  few  turns  of  [023].  Note  that  we  let  the  recursion  to  advance  one  step  at  a  time,  checking  if  the 
desu-ed  bindings  for  other  variables  have  been  reached,  that  is,  if  Args  is  now  unifiable  with  Arl.  The  reader  should 
note  that  the  problem  is  not  merely  in  removing  left  recursion  in  [03'].  Indeed,  doing  so  in  a  standard  fashion  would 
not  do  any  good  because  as  a  result  we  would  prepose  the  order  of  literals  np  and  vp  in  [03'].  This,  however,  would 
be  subsequently  reversed  by  INVERSE,  because  Csem,  the  essential  argument  in  np,  is  not  bound  before  vp  is  exe- 
cuted. 

There  is  a  flaw  in  the  argument  given  above,  however.  To  see  it,  we  consider  a  simplified  version  of  the  "nor- 
malized" code  given  above. 


'"  A  similar  example,  though  on  ihe  meia-grammar  level,  is  given  in  Shieber  el  al.  (1989)  and  il  is  used  there  as  an  argument  for  introduc- 
ing a  mixed  top-do»TiAxxtom -up  evaluation  strategy  in  generation  'l>)is  becomes  unnecessary,  however,  once  the  grammar  is  normalized  or  IK- 
VERSE  modified  to  deal  inter-clausal  reordering. 

'^  Note  that  this  program  fragment  is  built  according  to  quite  a  diircrenl  design  than  those  obuined  from  the  stnng  grammar.  Here,  txjlh 
Args  and  Vsem  are  the  arguments  carrying  the  translauon,  or  semantics,  ol  vp  non-tcnninal:  Vsem  is  the  template  ihat  will  be  filled  at  the  lexicon 
level,  while  Args  is  used  to  collect  arguments  to  fill  this  template. 
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vp(Args,Sem)  :-  v(Arl,Sem),vpl(Arl,Args). 

vpl(Arl,Args)  :-  !. 

vpl(Arl,Args)  :-  vpl(Arl,f(Ajgs)),np. 

The  reader  may  note  that  this  code  will  work  only  if  there  exists  a  specific  relationship  between  the  values  of  vari- 
ables Arl  and  Args.  that  is  either  (a)  Args  =  Arl,  or  (b)  Arl  =  f"(Args).  There  is  nothing  in  the  code  above  to 
guarantee  that  this  relationship  holds.  Therefore,  the  "normalized"  code  is  still  ill-formed,  just  like  the  original.  This 
outcome  is  confirmed  by  the  strong  MSEAS  procedure  which  fails  to  find  any  MSEA  in  the  "normalized"  code  as 
well.  What  we  need  here  is  a  transformation  that  would  produce  the  code  that  would  survive  step  (3)  in  strong 
MSEAS  procedure.  The  general  pattern  is  as  follows: 

vp(Args,Sem) :-  v(Arl,Sem),vpl(Arl,Args). 
vpl(f(Arl),Args)  :-  vpl(Arl,Args),np. 
vpl(Args,Args). 

This  time  we  can  reduce  Arl  to  Args,  if  Arl  =  r(Args),  n>0.  If  this  is  not  the  case,  we  stop  with  failure.  Note  that 
now  (Arl)  is  a  MSEA  in  \pl  following  the  strong  MSEAS  procedure.  If  we  add  siring  variables  VI,  V2,etc.,  then 
we  obtain  also  another  MSEA:  {Vl,Arl).  Thus,  finally  the  code  is  well-formed,  and  reversible  at  that.  Note  also 
that  in  the  end  we  did  not  have  to  swap  the  order  of  clauses  dclining  vpl.  This  modified  normalization  process 
transforms  the  original  program,  consisting  of  clauses  [01]  lo  [15],  into  the  new  program,  as  shown  below. 

[01]  sent(Vl,V3,Sem):-np(Vl,V2,Sscm),vp(V2,V3,[Sscm],Scm). 
[02]  vp(Vl,V3,Args,Sem) :-  v(Vl,V2,Arl,Sem),vpl(V2,V3,Arl,Args). 
[03]  vpl(Vl,V3,[CsemlArl],Args)  :- 

vpl(Vl,V2,Arl,Args),np(V2,V3,Csem). 
[04]  vpl(Vl,Vl,Args,Args). 

[05]  v(Vl,V2,[lobj,Obj,Subj],give(Sub|,Obj,lobj)i  ;-  give(Vl,V2). 
[06]  v(Vl,V2,[Obj,Subj],love(Subj,Obj)) :-  lovc(Vl,V2). 
[07]  v(Vl,V2,[Subj],arrivc(Subj))  :-  amvc(Vl,V2). 
[08]love([loveslX],X). 
[09]  love([lovedlX],X). 
[10]give([giveslX],X). 
[11]  give([gaveiX],X). 
[12]  arrive([amveslX],X). 
[13]  arrivc((amvedlX],X). 
[14]  np((marylX].X,mary). 
[15]  np([johnlX],X,john). 
[16]  np([appleslX],X,apples). 

After  normalization,  the  parser  program  can  be  successfully  inverted.  The  only  change  to  be  done  by 
INVERSE  is  to  reverse  the  order  of  literals  in  clause  [01].  An  obvious  question  to  be  asked  at  this  point  is  how  gen- 
eral the  above  method  is,  and  what  other  rules  of  normalization  might  be  required  before  the  parser  is  fully  inverii- 
ble.  I  try  to  answer  only  the  first  part  of  this  question  here.  The  normalization  rule  described  above  seems  quite  gen- 
eral in  that  it  does  not  require  manipulating  of  literal's  internal  arguments,  and  the  changes  made  to  the  grammar 
have  always  a  local  character.  The  net  effect  of  this  transformation  is  a  code  that  can  be  effectively  evaluated  by  a 
top-down  interpreter,  even  though  the  original  code  couldn't.  The  code  normalization  stage  saves  the  the  runtime 
overhead  that  would  unescapably  result  if  we  had  a  more  elaborate  interpreter,  such  as,  for  example  the  mixed  top- 
down/boitom-up  method  proposed  by  Shieber  ei  al.  (1989). 

In  general  the  normalization  rule  discussed  above  can  be  described  by  the  following  pattern,  where  Sem  is  an 
essential  argument  in  x,  (Z,Sem)  is  a  MSEA  in  x',  and  all  other  arguments  are  omitted. 

x(Args,Sem) :-  z(Z,Sem),x'(Z,Args). 
x(Args,Sem) :-  x(f(Args),Sem),y.  ===>  x'(f(Z),Args) :-  x'(Z,Args),y. 

x(Args,Sem) :-  z(Args,Semj.  x'(Args,Args). 

z(Args,Sem) :-  w.  z(Args,Sem) :-  w. 

There  is  one  interesting  special  case  of  this  scheme.  When  literal  z  is  empty,  that  is  x(Args,Sem)  in  the  second 
clause  rewrites  into  an  empty  siring,  then  we  actually  need  to  inaoduce  one.  Without  it  we  cannot  assign  the  initial 
binding  to  variable  Z,  which  must  be  done  since  Z  is  an  essential  argument. 
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Finally,  we  need  to  decide  whether  the  iransformaiion  described  above  belongs  to  the  normalizer  or  perhaps  it 
should  be  somehow  integrated  into  the  inversion  process.  This  time  we  do  not  need  to  know  beforehand  if  the  origi- 
nal code  is  reversible,  but  we  need  to  know  that  ii  is  ill-formed  according  to  the  su-ong  MSEAS  procedure.  This  sug- 
gests thai  the  transfonnation  is  best  placed  as  a  subprocess  called  from  MSEAS  whenever  its  su-ong  version  fails  to 
find  a  MSEA  for  a  clause. 

4.3.  Enhancing  the  efficiency  of  the  generator 

The  method  of  reversing  a  Prolog  parser  described  in  section  3  does  not  yet  guarantee  that  the  obtained  gen- 
erator will  be  the  optimal  one.  It  appears,  however,  that  if  the  clauses  in  the  parser  conform  to  certain  requu-emenLs 
of  form,  a  very  efficient  generator  can  be  obtained.  This  section  describes  one  of  several  types  of  transformations 
that  can  be  used  in  order  to  put  the  parser  into  the  desired  form.  These  transformations  are  intended  to  be  used 
before  the  reversal  process  dcscnbcd  in  the  previous  section  is  applied.  The  reason  is  that  some  of  the  u-ansforma- 
lions  described  below  ma\  eliminate  the  need  for  reversing  of  entire  segment ,  of  the  parser. 

4.3.1.  Production  splitting 

Normalization  of  the  parser  code  prior  lo  inversion  can  lead  to  a  substantial  improvement  in  performance  of 
the  generator.  One  such  situation  arises  when  some  of  the  non-ierminals  on  tiie  right-hand  side  of  some  productions 
may,  in  some  cases,  conu-ibuie  null  components  to  the  translation  of  the  head  non-terminal  on  the  Ihs.  Moreover, 
the  "semantics"  of  the  non-terminal  on  the  leli-hand  side  contains  no  trace  of  the  empty  su-ing  producuon  being 
used.  In  other  words,  the  null  'translation'  of  the  non-terminal  on  the  rhs  is  "spliced"  into  the  translation  of  the  Ihs 
leaving  no  trace. 

In  such,  and  similar,  situations  the  cfticiency  of  the  generator  can  be  enhanced  if  the  parser  clauses  are 
appropriately  "prepared"  before  the  reversal  process  starts.  The  u-ansformation  we  want  to  suggest  here  is  applicable 
when  the  "semantics"  of  some  of  the  non-terminals  on  the  right-hand  side  of  a  production  contribute  either  uniquely 
identifiable  components  to  the  "semantics"  of  the  non-tcrminal  on  the  left,  or  else  they  conuibuie  null  components, 
in  which  case  their  presence  is  not  recorded  in  the  'semantics"  of  the  left-hand  side  non-terminal  at  all.  As  a 
specific  example  consider  the  following  clause  implementing  the  su-ing  of  left-modifiers  to  a  noun  (#  compresses  its 
first  list  argument  removing  all  null  components  and  deposits  the  result  in  P); 

ln(Ll,L5J^um,P) :- tpos(Ll,L2,Num,P]  ),qpos(L2,L3,Num,P2),apos(L3J-4J'3), 
npos(L4,L5,P4),#([Pl,P2,P3,P4],P). 

Each  of  tpos,  qpos,  apos  and  npos  u-anslates  either  into  a  unique  component  of  P,  such  as  [tpos.every]  or  [apos,ta]l], 
or  into  a  ml.  The  procedure  #  would  then  combine  lists  PI  to  P4,  eliminating  any  empty  list  from  among  them.  This 
clause  belongs  to  the  parser,  and  needs  to  be  modified  for  the  use  in  a  generator.  Our  inversion  algorithm  requires 
fronting  of  the  #  literal,  but  one  may  note  that  this  would  not  do  much  good.  Given  P,  the  generator  would,  in  the 
worst  case,  attempt  to  examine  all  possible  decompositions  of  the  list  structure  in  P  into  a  four-element  list.  In  gen- 
eral, the  number  D(k,n)  of  different  ways  to  decompose  the  list  of  n  elements  into  k  sublist  preser\ing  the  original 
ordering  of  elements  is  defined  by  the  following  recursive  equation: 

D(l,n)=l; 

D(k,n)  =  I"_^D(k-l,n-i)  fork>2. 

For  example,  D(4,4)=35,  D(4,5)=56,  D(4.6)=84,  D(4,7)=120,  etc.  This  is  an  unnecessary  waste  of  time  since  we 
know,  from  the  fact  that  components  of  P  are  uniquely  identifiable,  which  non-terminals  on  the  nght-hand  side  of 
the  clause  conu-ibuted  them.  A  better  approach  is  to  normalize  the  clauses  so  that  they  are  better  suited  for  the  needs 
of  generation.  'We  may  note  that  although  the  above  clause  works  fine  in  a  parser,  it  is  nearly  completely  useless  for 
a  generator.  'We  replace  this  production  and  all  the  productions  rewriting  tpos,  qpos,  apos  and  npos  by  a  group  of 
new  productions  that  split  the  above  clause  into  2k  new  clauses  where  k  is  the  number  of  non-terminals  on  the  right 
rewnting  to  nil.  All  the  clauses  implementing  xpos  ->  e  are  eliminated,  and  the  semantics  of  xpos  ->  const  is 
adjusted. 

In  general  we  may  propose  the  following  transformation.  Given  the  fragment  of  the  grammar  (string  vari- 
ables omitted): 

n„(P,) :-  s,(P,),s,(P3) s,(P,),#([PpP2,  -.PJ-Po)- 

Si([]). 
S2([]). 
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s,([]). 
we  replace  it  by  ihe  following  2*k  produclions  (w  here  n_,  i>0,  are  new  non-terminals): 

no([PjlP2]):-s,(P,),n,(Pj). 
Ti^(P) :-  n,(Pj. 
n,([P,IP2]):-S2(P,).n2(P,). 

n,(P):-n2(P). 

n,;;([P]):-s,(P). 

For  example,  the  clause  defining  literal  In  atmvc  is  replaced  by  the  following  new  code: 

ln3(Lli.2,[Pl]):- 

npos(Ll,L2,Plj. 
ln3(Ll,Ll,[]). 
ln2(Ll,L3,[PllP2]):- 

ln3(L2,L3.P2), 

apos(Ll,L2,Pl). 
ln2(L112,P2):- 

ln3(Ll,L2,P2). 
lnl(Ll,L3,[PllP2]):- 

ln2(L2J.3,P2), 

qpos(Ll,L2,Pr). 
lnl(LlJ.2,P2)  :- 

ln2(Ll,L2,P2). 
ln(Ll,L3,[PllP2]):- 

lnl(L2a_3,P2), 

tpos(Ll,L2,Pl). 
ln(Ll,L2,P2):- 

lnl(Ll,L2,P2j. 

A  slight  variation  of  the  above  rule  can  be  proposed  m  situations  v,  hen  some  of  the  s  literals  do  not  rewrite  to  empty 
strings.  Thus,  given  the  following  fragment 

npCPp) :-  SjCPjj.s^CPp r(Q) s^(P^),#([P,.P„  ...,0,  ....PJ.P,). 

s,([]). 

S2([]). 

s;([]). 
where  r(Q)  does  not  rewrite  to  an  empty  siring,  we  replace  it  by  the  following  2*k+l  new  productions: 
no([P,IP2]):-s,(P,),n,(P2). 
no(P):-n,(P). 

n,([P,IP2]):-S;(P,),n2(P2). 
n,(P)  :-  n^CP). 

n;('[PJP,]):-r(P,),n^^,(P,). 

n^  ,([P]) ;-  s^(P). 
n,.,([]). 

As  an  example  consider  the  following  clause  defining  the  top-level  structure  of  a  "regular"  noun  phrase,  where  both 
In  and  m  can  rewrite  into  an  empty  string,  but  n\  ar  must  always  be  non-empty. 

nstgo(Nl>J4,[nplP])  :- 
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ln(Nl,N2,Pl), 

nvar(N2,N3,P2), 

m(N3,N4.P3), 

@(Pl,[(n,P2]IP3],P). 

This  production  is  normalized  using  ihc  modilicaiion  of  the  spliuing  rule  given  above.  The  resulting  program  is 
given  below. 

nsigo2(NlJ^2J'l):- 

m(Nl,N2,Pl). 
nsigo2(Ni;sll,[]). 
nstgol(N]JSI3,[[n,P2]IP3]):- 

nstgo2(N2,N3J'3), 

nvar(Nl,N2,P2). 
nstgo(Nl>'2,[nplP2J):- 

nstgol(Nl,N2,P2). 
nstgo(NlJ>J3,[nplP])  :- 

(a)(PlJ>2,P), 

nsigol(N2,N3,P2), 

ln(Nl,N2,Pl). 

This  last  example  shows  thai  the  splitting  rule  (or  iLs  variations)  is  applicable  whenever  any  of  the  non-terminals  on 
the  right-hand  side  of  a  production  rewrites  to  nil,  even  though  there  m?y  be  no  explicit  producuon  s_([]),  but  we 
ma)'  have  only  s  — >*  nil.  It  should  be  stressed  here  thai  we  must  be  careful  in  removing  all  the  empty-string  pro- 
ductions, because  if  we  leave  any  around  the  generator  will  produce  duplicate  outputs.  For  example,  nsigo2  above 
rewrites  to  m  which  is  defined  by  the  following  clauses: 

m(RlJ?3,Num,[PllP2])  :- 

mval(Rl,R2,Num,Pl), 

m(R2,R3J<um,P2). 
m(RJ^,Num,[]). 

Thus,  m  can  rewrite  into  an  empty  siring  in  the  second  of  these  clauses,  but  we  cannot  simply  remove  it,  because  it 
also  serves  as  a  stop  condition  to  the  first  rccursne  clause.  Instead,  we  modify  the  above  code  as  follows,  which  is 
actually  in  line  with  the  transformation  described  above: 

m(RI,R3JSIum,[PIIP2]):- 

mval(Rl,R2Js'um,Pl), 

ml(R2,R3,Num.P2). 
ml(RlJ?3Jvlum,[PllP2]):- 

mval(RlJ^2JMum,Pl), 

ml(R2,R3J^um,P2). 
ml(RlJ^lJsIum,[]). 

4.3.2.  Path  compression  and  path  merging 

In  some  situations  a  special  path  compression  algorithm  may  transform  some  of  the  non-local  semantics  chain 
rules  into  local  semantics  non-chain  rules.  If  we  could  eliminate  all  non-local  semantics  rules,  then  the  obtained  pro- 
gram would  actually  become  bi-directional,  although  its  efficiency  might  have  suffered  due  to  the  need  for  repeated 
re-parsing/re-generaung  of  the  same  substrings.  The  efficiency  problem  may  be  sometimes  averted  if  path  merging 
is  performed  at  the  same  time,  the  process  that  would  collapse  the  paths  generating  from  the  same  structure.  The  net 
effect  of  the  combined  transformations  is  that  of  "lifting"  certain  translation  su-uctures,  associated  with  "semantics" 
arguments  of  literals,  from  non-terminals  sitting  lower  in  the  grammar  tree  to  those  sitting  higher  up  the  tree.  This 
means  that  some  paths  will  be  split,  and  some  decisions  will  be  made  earlier  in  generation.  The  efficiency  problem 
can  be  controlled  if  these  early  decisions  are  deterministic,  that  is,  there  will  be  no  need  to  retrace  the  same  steps 
along  another  path.  Another  problem  that  must  be  taken  into  account  is,  sometimes  substantial,  growth  in  the  size  of 
the  grammar.  It  would  be  certainly  undesirable  if  the  size  of  the  grammar,  counted  as  a  number  of  different  produc- 
tions, was  directly  dependent  upon  the  size  of,  say,  verb  lexicon.  Thus,  the  "lifting  transformation"  should  only  be 
used  for  a  localized  "tuning"  of  the  parser  code  before  its  inversion. 
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As  an  example  consider  the  following  fragment  of  a  parser: 

assenion(Al,A41,WHQ,P)  :-  [1] 

sa(Al,All,PAlj, 

subjeci(A  1 1  ,A2,WHQ,Num,Pl ), 

sa(A2,A21,PA2j, 

verb(A21,A3,SisJs'um,P2), 

sas(A3,A31,Sls,PA3), 

object(A31,A4,0,Sls,[Num,Pl],P2,PSA,P), 

sao(A4,A41,0,PA4), 

#([PA1,PA2J'A3,PA4],PSA). 
objeci(01,02,tovo,Sis.Pl,P2,PSA,[P2,lsubjcct,Pl],[object,P3]IPSA]):- 

lovo-verb(Sls), 

lovo(01,02Pl,P3). 
objeci(01,02,nstgo,SlsJ'l,P2,PSA,[P2,[subjeci,Pl],[objeci,P3]IPSA]):- 

nsigo-verb(Sts), 
nslgo(01,02,Num.P3). 

The  chain  rule  for  assertion  can  be  replaced  by  two  non-chain  local-semantics  rules  eliminating  the  non-terminal 
object  and  compressmg  the  three  clauses  into  two,  by  expandmg  ob]cci  literal  in  the  assertion  clause  and  replacmg  it 
by  the  nghi-hand  side  of  appropnaicK  inst;tniiaicd  object  clause,  as  shown  below: 

assertion(AlA41,WHQ,[P2,|subicci.Pl|,|objcct.P3]IPSA]):-  [2] 

sa(Al,All,PAl). 

subjcct(A  1 1 ,  A2.\VHQ,N  um.P  1 ), 

sa(A2,A21,PA2), 

verb(A21,A3,Sts.Num,P2), 

sas(A3,A31,Sls.PA3j, 

lOvo-verb(Sts), 

lovo(01.02,Pl,P3), 

sao(A4,A41,0,PA4), 

#([PA1,PA2,PA3,PA4],PSA). 
assertion(Al,A41,WHQ,[P2,lsubject,PlJ,[ohiect,P3)IPSA]):- 

sa(Al,All,PAl), 

subject(All  .A2,WHQ,Num,Pl ). 

sa(A2.A21,PA2), 

verb(A21,A3,Sts,Num,P2), 

sas(A3,A31,Sts,PA3), 

nstgo-verb(Sts), 

nstgo(0 1,02, Num. P3), 

sao(A4,A41,OJ'A4), 

#([PA1,PA2,PA3,PA4],PSA). 

The  problem  with  this  code  is  that  we  have  no  way  of  telling  w  hich  of  the  two  clauses  should  be  used  in  any  particu- 
lar case  of  generation,  because  they  both  require  the  same  su"ucture  of  the  underlying  form.  Moreover,  if  we  fire  the 
wrong  one,  which  we  do  not  know  until  reaching  tovo  or  nstgo  literals,  we  will  have  to  back-up,  throwing  away  suc- 
cessfully generated  subject,  verb,  and  perhaps  some  sentence  adjuncts,  only  to  re-generate  them  anew  while  evaluat- 
ing the  other  clause.  To  correct  this  we  merge  fragmenus  of  the  rhs's  of  both  clauses,  and  break  them  back  into  three 
clauses,  as  shown  below: 

assenion(Al,A41,WHQ,[P2,[subject,Pl],[objcct,P3]IPSA]) :-  [3] 

!,sa(Al,AllJ'Al), 

subject(All,A2,WHQ,Num,Pl), 

sa(A2,A21,PA2), 

verb(A21,A3,StsJslum,P2), 

sas(A3,A31,Sts,PA3), 

obje<;tl(A31,A4,0,StsJ>l,P2,PSA,P3), 

sao(A4,A41,0,PA4), 

#([PA1,PA2J>A3,PA4],PSA). 
objecil(01,02,iovo,Sts,PlJ>2,PSAJ'3):- 
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lovo-verh(SLs), 
tovoCOl.OZPl.PS). 
objecll(01,02,nsigo,Sis,Pl,P2,PSA,P3):- 
nsigo-verb(Sti;), 
nstgo(01,02^um,P3). 

As  ihe  result,  we  lifted  the  translation  scheme  [P2,[subject,Pl ], [object J'3]IPS A]  from  object  to  assertion.  In  this 
way,  the  decision  to  take  a  specific  path  in  generation  can  be  made  earlier  in  the  process,  and  some  of  the  non-local 
semantics  rules  can  be  eliminated.  This,  in  turn,  reduces  the  need  for  code  inversion.  After  this  transformation  the 
assertion  clause  is  nearly  bi-du-ectional,  except  for  the  list  splicing  primitive  which,  for  generation,  must  be  placed 
in  front  of  all  sentence  adjunct  literals.  We  use  objetil  in  [3]  rather  than  object  to  prevent  other  object  clauses,  with 
different  semantics,  to  be  fired  from  the  rhs  of  a.sseriion.  To  illustrate  this,  we  add  two  more  clauses  to  [1],  as  shown 
in  [4]. 

object(01,02,vo,Sis.Pl,P2,PSA,|P2,P3IPSA]) :-  [4] 

vo(01,02Pl,P3). 
vo(Vl,V41,Pl,P4j  :- 

vb(Vl,V2,Sis,inf,P2), 

sas(V2,V3,Sls,PAl), 

object(V3.V4,0,Sts,Pl,P2.PSA.P4), 

sao(V4,V41,O.PA:). 

@(PA1,PA2,PSA). 

When  the  "lifting"  transformation  is  applied  to  (1]  and  |4]  taken  together,  four  new  clause  are  added  to  [3],  as 
shown  in  [5]  below.  The  reader  may  note  the  new  non-icrmmal  obicct2  which  is  called  only  if  the  paiicrn 
[P2J'31PSA]  is  recognized  at  the  assertion  level. 

assertion{Al,A41,WHQ,fP2J'3IPSA])  :-  [5] 

!,sa(Al,All,PAl), 

subject(All,A2,WHQ,Num,Plj, 

sa(A2,A21,PA2), 

verb(A21,A3,StsJMum,P2), 

sas(A3,A31,Sts,PA3). 

object2(A31,A4,0,Sis,Pl,P2,PSA,P3). 

sao(A4,A41,OJ'A4), 

#([PA1,PA2J'A3,PA4]J'SA). 
objecl2(01,02,vo,Sts,Pl.P2,PSA,P3):- 

vo(01,02,Pl,P3). 
vo(Vl,V41,Pl,[P2,(subject,Pl],[objeci.P3]IPSA]):- 

!,vb(Vl,V2,Sts,inf,P2), 

sas(V2,V3,Sts,PAl), 

objecil(V3,V4,0,Sis,Pl,P2,PSA,P3), 

sao(V4,V41,OJ'A2), 

@(PA1J>A2,PSA). 
vo(Vl,V41,Pl,[P2J'3IPSA])  :- 

!,vb(Vl,V2,Sts,inf,P2), 

sas(V2,V3,SlsJ'Al), 

object2(V3,V4,0,Sts,Pl,P2,PSA,P3), 

sao(V4,V41,OJ'A2), 

@(PA1PA2,PSA). 

The  reader  should  note  that  the  lifting  uansformaiion  must  also  lake  care  of  the  arguments  to  the  new  non-terminals 
(here,  objecll  and  object!).  Since  these  v,ill  be  derived  from  the  arguments  to  the  old  non-terminal  (here,  object), 
the  general  rule  is  as  follows: 

(1)  Initially,  the  new  non-terminal,  say  XI,  inhcriLs  all  the  arguments  of  the  old  non-terminal,  say  X,  which  are 
not  explicitly  lifted.  (In  our  last  example,  [P2,P3IPS  A]  is  explicitly  lifted,  so  object2  has  initially  the  follow- 
ing arguments:  object2(0] .02.vo.Sts.P]  f2,PSA).) 

(2)  Add,  as  new  arguments,  those  free  variables  found  in  the  lifted  pattern  which  are  not  already  arguments  to 
XI.  (In  our  example,  we  need  to  add  P3  to  object2.) 
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(3)  Remove  those  argumenis  from  XI  which  contain  none  of  the  variables  appearing  on  the  nghi-hand  side  of 
any  of  the  clauses  defining  an  expansion  for  XI.  (If  we  assume  that  the  only  expansion  for  objecil  is 
vo(0] ,02,P] .P3),  then  P2  can  be  dropped  as  an  argument  to  object!.) 

Fmally,  we  may  note  that  the  lifting  transformation  is  also  applicable  in  cases  when  the  patterns  are  put  together  by 
dedicated  literals,  such  as  combine,  @  or  #,  rather  than  by  ready-made  terms.  In  such  cases  we  lift  the  pattern- 
forming  literal,  removing  it  from  its  present  location  and  placing  it  in  front  of  the  right-hand  side  of  the  clause  to 
which  the  lifting  is  made.  All  other  aspects  of  the  transformation  remain  unchanged.  For  example,  if  we  had 

object(01,02,vo,Sts,Pl,P2PSA,P):- 
vo(01,02J'l,P3), 
combine([P2,P3,PSA],Pj. 

then  the  resulting  assertion  clause  would  be; 

assertion(Al,A41,WHQ,Pj  :- 
combine([P2,P3,PSA],Pj, 
sa(Al,All,PAl), 
subject(A  1 1  ,A2,WHQ,Num,Pl ), 
sa(A2,A21.PA2), 
verb(A21,A3,Sts,Num,P2), 
sas(A3,A31,Sts,PA3), 
obiecl2(A31,A4,0,Sts,Pl,P2,PSA.P3), 
sao(A4,A41,0,PA4), 
#(,|PA1,PA2,PA3,PA4],PSA). 

Last,  but  not  the  least,  it  must  be  stressed  here  thai  in  order  to  benefit  from  the  "lifting"  transformation  the  generator 
must  be  able  to  make  deterministic  choices  among  the  paths  with  lifted  semantics,  or  else  it  will  be  running  through 
costly  back-ups.'^  This,  however,  may  not  always  be  possible.  Consider,  for  example,  the  following  clause. 

object(01,02,objecibe,Sts,Pl,P2,PSA.P3):- 
objecibe-verb(Sts),!, 
objectbe(01 .02  J-l  ,P2,PSA,P3). 

Here  lifting  of  variable  P3  from  object  to  assertion  docs  not  mark  a  unique  generation  path,  because  anything  can  be 
unified  against  an  uninstanuaied  variable.  In  such  a  case  the  lifung  transformation  makes  little  sense  and  we  are 
better  off  without  it.  Before  giving  up,  however,  we  should  consider  a  possibility  that  the  unique  semantic  pattern 
we  are  looking  for  can  be  lifted  from  literals  located  even  further  below  in  the  grammar  tree.  This  is  in  fact  the  case 
with  the  object  clause  above,  because  we  can  lift  patterns  associated  with  clauses  defining  objectbe.  In  other  situa- 
tions, when  two  patterns  are  not  sufficiently  dilfcrent.  they  may  be  made  more  specific  by  lifting  fragments  of  trans- 
lation structure  from  the  literals  further  below  in  order  to  replace  some  of  the  free  variables  in  these  patterns.  On  the 
other  hand,  we  do  not  want  to  go  too  deep  into  the  grammar  tree  to  find  our  unique  patterns.  On  the  one  exu-eme,  we 
might  have  to  go  as  far  as  the  lexicon,  which  would  have  the  unfortunate  effect  of  making  the  size  of  the  grammar 
proportional  to  the  size  of  the  lexicon.  The  reader  may  note  thai  the  following  grammar  is  not  a  good  choice  for  the 
lifting  transformation. 

sent(Sem) :-  np,vp(Sem). 
vp(Sem) :-  vp(Sem),np. 
vp(gives(X,YZ)). 
vp(loves(X,Y)). 
vp(walks(X)). 

The  basic  version  of  the  "lifting"  transformation  can  be  implemented  using  a  fairly  straightforward  algorithm.  A 
more  interesting  version  that  would  take  into  account  the  problems  discussed  here  is  still  under  investigation. 


Excessive  backtracking  can  be  prevented  by  using  the  cul,  as  shown  in  the  examples  above.  However,  the  cut  also  eliminates  non- 
determinism,  and  thus  reduces  the  power  of  a  non-deierminisuc  grammar. 
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5.  Conclusions 

In  this  paper  we  presented  an  algorithm  for  automatic  inversion  of  a  unification  parser  for  natural  language 
into  an  efficient  unification  generator.  The  major  characteristics  of  this  algorithm  include:  (1)  integration  of 
context-free  grammar  rules  with  context-sensitive  rules  such  as  morphological  agreement  and  "semantic"  transla- 
tions, within  a  single  inversion:  (2)  full  automatization  of  the  inversion  process;  and  (3)  maximum  efficiency  of  the 
generator  obtained  as  the  result  of  inversion.  In  fact,  the  inverted  parser  generator  behaves  as  if  it  was  "parsing"  the 
output  of  the  non-inverted  parser.  This  is  in  contrast  with  the  methods  where  the  inverted  parser  generator  operates 
by  making  a  number  of  guesses  (as  to  the  final  appearance  of  the  surface  suing)  which  are  subsequently  verified  or 
rejected  by  parsing  each  guessed  string  or  word  and  comparing  so  obtained  structure  with  what  is  known  to  the  gen- 
erator. 

This  paper  is  not  an  attempt  to  define  a  general  algorithm  for  reversing  programs  or  functions,  such  as  those 
discussed  by  McCai  hy  (1956)  or  Dijksffa  (1983),  among  others.  The  method  relies,  to  some  extend,  on  the  specific 
properties  of  a  unifi.;ation-based  parser  for  English,  and  its  top-down,  left-to-nght  character.  One  of  the  problems 
remaining  to  be  worked  out  is  a  precise  definition  of  what  type  a  grammar/parser  can  be  most  profitably  inverted 
using  the  method  presented  here.  The  reader  may  also  have  noted  that  we  did  not  discuss  what  other  problems  may 
need  to  be  solved  during  the  normalizauon  phase,  besides  the  few  cases  discussed  in  section  4. 
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Appendix  A  list  the  Prolog  code  of  an  actual  unification  parser  for  a  fragment  of  English.  Appendix  B  gives 
the  code  of  the  generator  obtained  by  inverting  this  parser  using  the  algorithm  presented  in  this  paper.  Finally, 
Appendix  C  lists  a  fragment  of  the  lexicon  used  by  both  the  parser  and  the  generator. 
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Appendix  A:  A  Prolog  parser  for  a  fragment  of  English 

@([XIL1],L2,[XIL3]) :-  (©(LI  J.2,L3). 

@([]J-X). 

#([XIL1],L2) :-  #(L1,L3),@(X,L3,L2),!. 

miu). 

mem(X,[XIL])  :-  !. 

mem(X,[YlL])  :-  mem(X,L). 

parse(S,P) :-  senience(S,[],P). 

senience(Sl,S2,[asserl,P])  :-  asseriion(Sl,S2,asn,nogap,P). 

seniencc(S  1  ,S2,P) :-  question(S  1  ,S2,P). 

senience(Sl,S2,Pj ;-  imperauve(Sl,S2,P). 

assertion(Al,A41,WHQ,Gap,P)  :- 

sa(Al,All,PAl), 

subjeci(All,A2,WHQJMum,Pl), 

sa(A2,A21,PA2), 

verb(A21,A3,Slsl,Num,P2), 

sas(A3,A31,Sisl,SLs2,PA3), 

objeci(A31,A4,0,Sts2,Gap,asscri,lNum,PlJ.P2,PSA,P,). 

sao(A4,A41,0,PA4), 

#([PA]  J'A2,PA3,PA4],PS  A). 
queslion(Ql,Q2,[askif,P]) :-  nesnoq(Ql,Q2,ynq.P). 
qucsiion(Ql,Q2,P) :-  whqn(Ql,Q2.P). 
question(Ql,Q2,P)  :-  whq(Ql,Q2,Pj. 
imperative(Il, 13, [command J*])  :- 

saai,12,PSA), 

voG2,I3,Num,you,P2), 

@(P2,PSA,P). 
yesnoq(Al,A41,WHQ,P)  :- 

auxverb(Al,A2,SLs,Num,P2j, 

subject(A2,A3,WHQ,Num,Pl ), 

sa(A3,A31J'Al), 

object(A3 1 ,  A4,0,Sts  ,nogap,ycsno,|  N  urn  ,P  1  ]  .P2  ,PS  A  ,P), 

sao(A4,A41,0,PA2), 

@(PA1,PA2,PSA). 
whqn(Wl,W4,[asicwh,P2,P3IPSA])  :- 

saO'l,W2,PSA), 

intpro(W2,W3,P2), 

resiq(W3,W4J'3). 
restq(Rl,R2J') :-  yesnoq(Rl,R2,whq,Pj. 
resiq(Rl,R2J') :-  assenion(R14^2,whq,nogap,P). 
restq(Rl,Rl,[]). 

intproai,I2,[np,P]) :-  whwordCIl.nj'). 
whq(W2,W4,[P2J'3])  :- 

wher2(W2,W3,P2), 

yesnoq(W3,W4,whq,P3). 
wher2(Wl,W2J')  :-  whques(Wl,W2,P). 
wher2(Wl,Wl,n). 
whnqn(Wl,W3,[askwh,Pl,P2]j  :- 

whn(Wl,W2,Pl), 

reslq(W2,W3J>2). 
whn(Wl,W2,P)  :-  nstgo(Wl,W2JMum,nogap,P). 
objeci(01 ,02,vo,Sts,Gap,yesno,Pl  ,P2 J-S A,[P2,P3IPS A])  :- 

vo(01,02,GapJ^um,PlJP3). 
objeci(01,02,tovo,Sis,Gap,N,PlJ>2,PSA,[P2,[subjeci,Pl],[objeci,P3]IPSA]) 

tovo-verb(Sts), 

lovo(01,02,GapJ'l,P3). 
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ob|cct(01,02,nstgo,Sis,Gap,N,Pl,P2,PSA,|P2,|sub|cci,Pll,|ob|cci.P3]IPSAl)  :- 

nsigo-verb(Sls), 

nsigo(01,02.Num,Gap,P3). 
objeci(01,02,null,Sis,nogapJV,Pl,P2,PSA,|P2,lsubicci,Pl)IPSA]):- 

nullobj-verb(Sis), 

nullobj(01,02). 
object(01,02,lhats,S[s,Gap,N,Pl,P2,PSA,[P2,[subjcci,Pl],lobjcci,P3]IPSA]j  :- 

thais(01,02,Gap,P3). 
objeci(01,02,pn,Sts,Gap,N,Pl,P2,PSA,[P2,|subjcci,Pl],[objcci.P3]IPSA])  :- 

pn-vcrb(Sts,PP), 

pn(01,02,GapJ^P,P3) 
objeci(01,02,obiecibc,Sts,Gap,N,Pl,P2,PSA,P3j  :- 

objccibe-verb(Sts),!, 

objecibc(01,02,Gap,Pl,P2.PSA,P3). 
objecibc(01,02,nogap,PlJ'2,PSA,P)  :- 

objbe(01,02.Pl,P3), 

@(P3,PSA,P). 
objeclbe(01,02,Gap,Pl  J>2,PSA,P)  :- 

venpass(01,02,Gap,Pl,P3), 

@([P2,P3],PSA,P). 
objecibc(01 ,02,Gap,Pl ,P2.PSA,P)  :- 

vingo(01,02,Gap,Pl,P3), 

@(Fp2,P3].PSA,P). 
nullobj(N,N). 
objbe(01,02J'l,[P3,[subjcci,Pl]])  :- 

adj(01,02,P3). 
objbe(01,02,Pl,[be,[subject,Pl],[objcci,P31l):- 

nsigo(01 ,02,Num,nogap,P3). 
objbe(01,02,Pl,[t>c,[subjea,Pl],P3])  :- 

pn(01,02,nogap,PP,P3j. 
passobj(S  1  ,S2,pn,Pl ,P2,[[objeci,Pl ],P3i )  :- 

pn(Sl,S2,nogap,PP,P3). 
passobj(Sl,S2,objbc,P].P2,l|object,P3]]):- 

objbe(Sl,S2J^l,P3). 
passobj(Sl,Sl,null,Pl,P2,[lobjeci,Pl]]). 
lovo(Tl,T41,Gap,Pl,P):- 

lo(Tl,T2), 

verb(T2,T3,Slsl,inf,P2), 

sas(T3,T31,Stsl,Sis2,PAl), 

object(T31,T4,0,SLs2,Gap,iovo,Pl,P2,PSA,Pj, 

sao(T4,T41,OJ'A2), 

@(PA1,PA2J'SA). 
nstgo(N>I,Num,var,[np-gap,var]). 
nstgo(Nl  J>J4,Num,nogap,[nplPjj  :- 

ln(Nl,N2,Num,Pl), 

nvar(N2jsl3JMumJ>2), 

m(N3,N4>Ium,P3), 

@(Pl,[[n,P2]IP3]J'). 
ln(Llj:.5,Num,P)  :- 

tposCLlJ-2,Num,Pl), 

qpos(L2J-3,Num,P2), 

apos(L3,L4,P3), 

npos(L4a.5,P4), 

#([P1,P2J'3,P4],P). 
tpos(Tl,T2,Num,[[l-pos,P]])  :- 

det(Tl,T2JMum,P). 
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tpos(Tl,T2,Num,[ll-pos,P]])  :- 

whln(Tl,T2,P). 
tpos(Tl,T2,Num,P):- 

howqsig(Tl,T2J'). 
tposCT.TJMumJ]). 
whln([whallVv'],\V,whal), 
whln([whichlW],W,which). 
howqstg([how,manylH],H,[howmany]). 
howqslg([how,muchlH],H,[howmuch]). 
qpos(Ql,Q2JMum,[[couni,P]])  :- 

couni(Ql,Q2J«Jum,P). 
qpos(Q,Q,Num,l]). 
apos(Al,A2,[[adjJ']])  :- 

adj(Al,A2,P). 
apos(Al,A2,[[a-pos-ving,P]])  :- 

ving(Al,A2,S.P). 
apos(Al,A2,[[qn-pos,P]]:)  :- 

qn(Al,A2,P). 
apos(A,A,[]). 

npos(NlJsI3,[|n-po.s,[np,P]]]);- 
lcdn(Nl,N2,Pl), 
noun(N2,N3,Num,P2). 
@(P2,P1,P). 
npos(N,N,[]). 
lcdn(LlJ.2,[[adj,P]])  :- 

adj(Ll,L2,P). 
lcdn(L,L,I]). 

qn(Ql,Q3,[np,[noun,P2],[couni,Pl]]):- 
coum(Ql,Q2JMum,Pl), 
noun(Q2,Q3,Num,P2). 
nvar(NlJM2,Num,P)  :-  noun(Nl,N2,Num,P). 
nvar(Ni;vI2,Num,P)  :-  pro(Nl,N2,Num,P). 
m(Rl,R3,Num,[PllP2]):- 
mval(Rl,R2,Num,Pl), 
m(R2,R3,Nuin,P2). 
m(R,RJ«Jum,[]). 

mva](Rl,R2,Num,P)  :-  pn(Rl,R2,nogap,PP,P). 
mval(Rl,R2,Num,[m-v.hlP])  :- 
vingo(Rl  ,R2,nogap,var,P). 
mval(Rl,R2,Num,[m-whlP])  :- 

venpass(Rl  ,R2,nogap,var,P). 
mval(Rl,R3,Num,[ni-whJ>J)  ;- 
wh-ihai(RlJ(2), 
vo(R2J^3,nogap,Num,varJ'). 
mval(Rl,R3,Num,[ni-whJ'])  :- 
wh-that(Rl,R2), 
assenion(R2J^3jTi-wh,var,P). 
pn(Nl,N3,GapJ'P,[Pl,P2]);- 
prep(Nl>I2J>l), 
mem(Pl,PP), 

nstgo(N2JM3,Num,GapJ^). 
subjeci(Sl,S2,WHQ,NumJ') ;-  nstgo(Sl,S2,Num,nogap.P). 
subjeci(S  1  ,S  1  ,whq,Num,  var). 
passagenUAl.AS.GapP)  :- 
by(Al,A2J'l), 
nstgo(A2,A3,Num,GapJ'). 
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lhals(Tl,T3,Gap,P)  :- 

lhat(TI,T2), 

asscrtion(T2,T3,ihats,Gap,P). 
vo(Vl,V41,Gap,Num,Pl,P4)  :- 

vb(Vl,V2,Stsl,Num,P2), 

sas(V2,V3,Stsl,Sls2J^Al), 

objeci(V3,V4,0,SLs2,Gap,voJ'l,P2,PSA,P4j, 

sao(V4,V41,0,PA2), 

@(PA1J'A2,PSA). 
vingo(Vl,V41,GapJ'l,P4):- 

ving(Vl,V2,StslJ>2), 

sas(V2,V3,Slsl,Sls2J^Al), 

objeci(V3,V4,0,Sls2,Gap,vingo,Pl,P2,PSA,P4j, 

sao(V4,V41,0,PA2), 

@(PA1PA2,PSA). 
veno(Vl,V41,Gap,Pl,P4)  :- 

ven(Vl,V2.Stsl,P2), 

sas(V2,V3,Sisl,Sts2,PAl). 

objeci(V3,V4,0,Sls2,Gap,veno,Pl  ,P2.PS  A.P4 ), 

sao(V4,V41,0,PA2j, 

@(PA1,PA2,PSA). 
venpass(Vl,V5,nogap,Pl,P)  :- 

ven(Vl,V2,Sls,P2), 

sa(V2,V3,PAl), 

passobj(V3,V4,0,Pl  ,P2,P4), 

sao(V4,V5,0,PA2), 

#([[P2,[subicct,anyone]lP4J,PAl,PA2].P). 
venpassCVl.Ve.GapJ'l.P)  ;- 

ven(Vl,V2,S,P2), 

sa(V2,V3,PA]), 

passageni(V3,V4,Gap,P4), 

passobj(V4,V5,0,Pl  ,P2  PS), 

sao(V5,V6,0,PA2), 

#([rre,[subjcci,P4]IP5]J'Al,PA2]J'). 
venpass(Vl,V6,Gap,Pl,P)  :- 

ven(Vl,V2,S,P2), 

sa(V2,V3,PAl), 

passobj(V3,V4,pn,Pl  ,P2  ^"4), 

passagent(V4,V5,Gap,P5), 

sa(V5,V6,PA2j, 

#([[P2,[subjeci,P5]IP4]J'Al,PA2],P). 
sao(Sl.Sl,null,[]):-  !. 
sao(Sl,S2,nulIJ'):-!,fajl. 
sao(Sl,S2,0,P) :-  sas(Sl,S2,[any]J>V,P). 
sa(Sl.S2J') :-  sas(Sl,S2,[any],PVJ>). 
sas(Sl,S3,PVlJ>V3,[PllP2]):- 

saval(Sl,S2,PVlJ'V2,Pl), 

sas(S2,S3J'V2,PV3J>2). 
sas(Sl,Sl,PVlJ'V2,[])  :-  unislr(PVl  J'V2). 
saval(Sl,S2J'V,PV,[advJ^]) :-  adv(Sl,S2,P). 
saval(Sl,S2PVl,PV2J>) :-  sava]](Sl,S2,PVl,[],PV2.P). 
savall(Sl,S2,[tovolPV]J'Vl  J'Vl.P) :-  !,savall(Sl,S2,PV,PVl,PV2J'). 
savall(Sl,S2,[ntovolPV],PVlJ'V2,P):-!,savall(Sl,S2,PV,PVl.PV2,P). 
sava]l(Sl,S2,[nstgolPV]J>Vl,PV2J') :-  !,savall(Sl,S2,PV,PVl  J'V2J'). 
savall(Sl,S2,[[pnlPN]IPV],PVlJ'V2,P):-!,savall(Sl,S2,PV,PVl,PV2,P). 
savall(Sl,S2,[objectbelPV]J'Vl,PV2,P):-!,savall(Sl,S2,PVJ>Vl,PV2J>). 
saval  1  (S 1  ,S2,[0THERIPV] ,PV  1  ,PV2,P) : - 
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!,savall(Sl,S2,PV,[OTHERIPVl],PV2,P). 
savall(Sl,S2,[],[],[],P):-  !,fail. 

savall(Sl,S2,[],PVJ'V,[in-ordcr-lo,P])  :- iovo(Sl,S2,nogap,pro,P). 
savall(Sl,S2,[],PVJ'V,P) :-  pn(Sl,S2,nogap,PP,P). 
objecibe-verb(Sts) ;-  mcm(objccibc,Sis). 
tovo-verb(Sls) :-  mem(iovo,Sis). 
nstgo-verb(Sls) :-  mem(nsigo,Sis). 
nullobj-verb(Sts) :-  mem(nullobj,Sis). 
pn-verb(Sts,PP) ;-  mem([pnlPP],SLs) 


vb(X,Y,Sts,Num,V) 
vb(X,Y,Sts,Num,V) 

vb(X,Y,Sts,Num.V) 


verb(X,Y,Sls,Num,V),l. 

-  ven(X,Y,Sis,V),l. 

-  ving(X,Y,Sis,V),l. 
auxverb(Vl,V2,S(5jMum,P) :- dcf(verb,P,aux,Sis),l,vrb(Vl,\'2,Num,P). 
auxverb(Vl,V2,SLsjS'um,Pj  :- vrb(Vl,V2,Num,P),dcf(verb,P,aux,0st),@(X,Sls,0st). 
verb(Vl,V2,Sis>Jum,P)  :- vrb(Vl,V2,Num,P),def(vcrb,P,Aux,Sls),l. 
verb(Vl,V2,Stsjslum,P):- vrb(Vl,V2,Num,P),def(vcrb,P,Aux,0st),@(X,SLS,0st). 
vcn(Vl,V2,Sls,P) :-  vrb(Vl,V2.en,P),def(verb,P,Aux,Sts),!. 
ven(Vl,V2,Sls.P):- vrb(Vl,V2,en,Pj,dcf(vcrb,P,Aux,0st).(«(X,Sts,0slj. 
ving(Vl,V2.SLs,P) :-  vrb(Vl,V2,ing,P),dcf(vcrb,P,Aux,SLi).!. 
ving(Vl,V2,StsJ') :- vrb(Vl,V2,ing,P),def(vcrb.P,Aux.0su,@(X,Sis,0si). 
unislr(S,S) :-  !. 

unistr([EISl],rEIS2]) :-  unisir(Sl,S2), 
unisir([EISl],S2):-@(X,[EIY],S2),(a(X,Y,S3),l,unisir(Sl.S3j. 
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Appendix  B:  An  inverted-parser  generator  for  a  fragment  of  English 

@([XIL1]X2,[XIL3]):-@(L1J-2,L3). 

#([XIL1],L2) :-  @(X,L3.L2),#(L1,L3). 

#([],[]). 

mem(X,[XIL])  :-  !. 

mem(X,[YIL])  :-  mem(X,L). 

parse(SJ') :-  senience(S,[]  J"). 

senience(Sl,S2, [assert J"])  :-  assertion(Sl,S2,asn,nogap,P). 

sentence(Sl,S2,P) :- question(Sl,S2.P). 

sentencc(Sl,S2J'j :-  imperauve(Sl,S2,P). 

assertJon(Al,A41,WHQ,Gap,P)  :- 

object(A31,A4,0,St52.Gap,asscrt,[Nuni,Pl],P2,PSAJ'j, 

subject(All,A2,W'HQJs!um,Plj. 

verb(A21,A3,Slsl,Num,P2i, 

#([PAl,PA2,PA3,PA4],PSAj, 

sa(Al,All,PAl), 

sa(A2,A21,PA2j, 

sas(A3,A3 1  ,Slsl  ,Sts2.PA?), 

sao(A4,A41,0,PA4). 
quesiion(Ql,Q2,[askif,P])  :-  yesnoq(Ql,Q2,ynq,Pj. 
quesiion(Ql,Q2,P)  :-  whqn(Ql,Q2,P). 
question(Ql,Q2,Pj  :-  v.'hq(Ql,Q2,Pj. 
imperaiive(ll,I3,[command,P]j  :- 

(a)(P2,PSA,P), 

saai,I2,PSA), 

vo(I2,I3,Num,you,P2). 
yesnoq(Al,A6,WHQJ'):- 

objecl(A4,A5,0,Sts,nogap,yesno,[Num,Pl],P2,PSA,Pj, 

auxverb(Al  ,A2,SLs,Num,P2), 

subjcci(A2,A3AVHQ,Num,Pl.). 

@(PA1,PA2J'SA), 

sa(A3,A4J'Al), 

sao(A5,A6,OJ^A2). 
whqn(Vv'l,W4,[askwhP2,P3IPSA])  :- 

sa(Wl,W2,PSA), 

inlpro(W2,W3J'2), 

resiq(W3,W4J'3). 
reslq(Rl,R2J') :-  yesnoq(Rl,R2,whq,P). 
restq(Rl,R2,P) :-  assertion(Rl,R2,whq,P). 
restq(Rl,Rl,[]). 

iniproaiJ2,[np,P]) :-  whword(Il,I2,Pj. 
whq(W2,W4,[P2,P3])  :- 

wher2(W2,W3J>2), 

yesnoqO'3,W4,whq,P3). 
wher2(Wl,Wl,[]). 

wher2(Wl,W2J^)  :-  whques(Wl,W2,P). 
whnqn(Wl,W2,[askwh,Pl])  :- 

whn(Wl,W2,Pl),!. 
whnqn(Wl,W3,[askwhJ'l,P2])  :- 

whn(Wl,W2,Pl), 

resiqO\'2,W3P2). 
whn(Wl,W2,P)  :-  nstgo(Wl,W2,Num,nogapJ'j. 
object(01,02,iovo,Sls,GapJM,Pl,P2,PSA,[P2,[subjeci,Pl],[objectJ'3]IPSA]) 

tovo-verb(Sts), 
lovo(01,02,Gap,Pl,P3). 
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object(01,02,nstgo,Sis,GapJM,PlJ'2,PSA,[P2,lsubjeci,Pl],[objeciJ'3]IPSA]) 

nsigo-verb(Sts), 

nsigo(0 1 ,02,Num,Gap,P3 ). 
objecKOl ,02,null,SLs,nogap,N,Pl  ,P2,PS A,[P2,[subjeciJ>l]lPS A])  :- 

nullobj-verb(Sts), 

nullobj(01,02). 
objeci(01,02,vo,Sis,Gap,yesno,Pl,P2J'SA,[P2J'3IPSA]):- 

vo(01,02,Gap,Num,PlJ'3). 
object(01,02,veno,Sis,Gap,NPl,P2PSA,[perf,[[P2IP3]IPSA]]):- 

veno(01,02,Gap,Pl,P3). 
ObjecKOl, 02,ihats,Sts,Gap,N,Pl,P2J»SA,[P2,[subjectPl],[objeci,P3]IPSA]): 

thats(01,02,Gap,P3). 

ObjecKOl, 02,pn,Sts,Gap,N,Pl,P2,PSA,[P2,[subjcciJ'l],[obje£t,P3]IPSA]):- 

pn-vcrb(Sls,PP), 
pn(01,02,Gap,PP,P3). 
objecK01,02,objecibc.Sis,Gap,N,Pl.P2,PSAJ'3):- 
objecibc(01,02,Gap,Pl,P2,PSA,P3j, 
obieclbc-vcrb(Sls). 
objectbc(01 ,02,nogap.Pl ,P2,PS A,Pj  :- 
@(P3,PSA.P), 
obibc(01,0:,Pl,P3). 
objecibc(01,02,Gap,Pl,P2,PSA,Pj  :- 
@([P2J^3],PSA,P), 
vcnpass(01,02,Gap,Pl,P3). 
objecibc(01,02,Gap,Pl,P2J'SA,P)  ;- 
@([P2,P3],PSA.P), 
vingo(01,02,Gap,Pl,P3). 
nullobj(N,N). 
objbe(01,02,Pl,[P3,lsubjcci,Pl]]j:- 

adj(01,02,P3j. 
objbe(01,02,Pl,[be,[.subjeci,PlJ,[objeci,P3]]):- 

nsigo(01,02,Num,nogap,P3). 
objbe(01,02J'l,[be,lsubjeci,Pl].P3])  :- 

pn(01,02,nogap,PP,P3). 
passobj(Sl,S2,pn,Pl,P2.[[objcci,Pl],P3])  ;- 

pn(Sl,S2,nogap,PP,P3). 
passobj(Sl,S2,objbe,Pl,P2,[[objeci,P3]]):- 

objbc(Sl,S2,Pl,P3). 
passobj(S  1  ,S  1  ,null,Pl  ,P2,[[objeci,Pl  ]] ). 
lovo(Tl,T41,GapJ'l,P):- 

objeci(T3 1  ,T4,0,Sis2,Gap,iovo,Pl  J*2,PSA,P), 
lo(Tl,T2), 

verb(T2,T3,Slsl,inf,P2), 
@(PA1,PA2,PSA), 
sas(T3,T31,Stsl,Sls2j^Al), 
sao(T4,T41,0,PA2). 
nstgo2(NlJ^2,NumJ>l):- 

m(Nl,N2JMum,Pl). 
nsigo2(NlJ41,Num,[]). 
nsigol(Nl  J^3,Num,[[nJ>2]IP3])  :- 
nvar(Nl>J2,Num,P2), 
nslgo2(N2J^3,Num,P3j. 
nstgo(NjNl,Num,var,[np-gap,varJj. 
nstgo(NlJvI2,Num,nogap,[nplP2])  :- 
nslgol(NlJvI2,NumJ>2). 
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nstgo(N  1  ,N3,Num,nogap,[nplP])  :- 

@(P1,P2J'), 

ln(Nl,N2,i\'um,Pl), 

nstgol(N2JS3,NumJ*2). 
ln3(Ll,L2,[Pl])  :- 

npos(LlJ-2,Plj. 
ln3(Ll,Ll,D). 
ln2(Ll,L3,[PllP2]):- 

apos(Ll,L2,Pl), 

ln3(L2,L3J'2). 
ln2(Ll,L2,P2):- 

ln3(L   ,L2P2j. 
lnl(Ll,L2,Num,[PllP2]):- 

qpos(LlJ_2,Num,Pl), 

ln2(L2,L3J'2). 
lnl(Ll,L2,Num,P2)  :- 

ln2(Ll,L2,P2). 
ln(Lia,3,Num,[PllP2]):- 

tpos(Ll,L2,Num,Pl), 

lnl(L2,L3,Num,P2j. 
ln(LlJ,2,NumJ'2)  :- 

)nl(Ll,L2,Num,P2). 
tpos(Tl,T2,Num,[t-posJ'])  :- 

det(Tl,T2,Num,P). 
ipos(Tl,T2,Num,[i-posJ'])  :- 

whln(Tl,T2,P). 
ipos(Tl,T2,Num.P)  :- 

hov.'qslg(Tl,T2P). 
whln([whatlW],W,whatj. 
whln([whichlW],W,which). 
howqsig([how,manylH],H,howmany). 
howqsig([how,muchlH],H,howmuchj. 
qpos(Ql,Q2Js'um,[count,P])  :- 

count(Ql,Q2JMum,Pj. 
apos(Al,A2,[adj,P])  :- 

adj(Al,A2,P). 
apos(Al,A2,[a-pos-ving,P])  :- 

ving(Al,A2,Sts,P). 
apos(Al,A2,[qn-pos,P])  :- 

qn(Al,A2,P). 
npos(Nl>I2,[n-pos,[np,[n,P2]]])  :- 

noun(NlJs'2,Num,P2). 
npos(Nl,N3,[n-pos,[np,[n,P2]J'l]]j  :- 

lcdn(Nl,N2J'l), 

noun(N2,N3,Num,P2). 
lcdn(LlJ-2,[adj,P])  ;- 

adj(Lia^2J'). 
qn(Ql,Q3,[np,[noun,P2],[coumJ'l]]):- 

counl(Ql,Q2JMum,Pl), 

noun(Q2,Q3,Num,P2j. 
nvar(NlJ^2,NumJ')  :-  noun(NlJ^2JVlumJ>). 
nvar(Nl  Js'2,NumJ')  :-  pro(Nljsl2,NumJ>). 
m(Rl,R3,Num,[PllP2])  :- 

mval(RlJ?2;^JumJ'lj, 

ml(R233;vIumJ>2). 
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ml(RlJ^3JvIum,[PllP2]):- 

mval(RlJ^2,Num,Pl), 

ml(R2J(3;vlum.P2). 
ml(RlJ?lJMum,[]). 

mva](Rl,R2,NumJ')  :-  pn(Rl  J^2,nogap,PPJ'). 
mva](Rl,R2,Num,[m-whlP])  :- 

vingo(Rl  ,R2,nogap,var,P). 
mva](Rl,R2,Num,[m-whlP])  ;- 

venpass(Rl  ,R2,nogap,var,P). 
mval(Rl,R3,Num,[m-whJ>])  :- 

wh-lhal(RlJ?2), 

vo(R2J?3,nogap,Num,var,P' 
mva](Rl,R3,Num,[m-wh,P])  :- 

wh-ihai(RlJ^2), 

asscriion(R2J^3^i-v.h,var,P). 
pn(Nl,N3,Gap,PP,[Pl,P2]):- 

prep(NlJS'2,Pl), 

mem(Pl,PP), 

nstgo(N2,N3,Num,Gap,P2). 
subjccKSl,S2,WHQ,Num,P) ;-  nstgo(Sl,S2Jslum,nogap,P). 
subjecUS  1  ,S  1  ,whq,Num,var). 
passagcni(Al,A3,Gap,P)  :- 

by(Al,A2,Pl), 

nsigo(A2,A3,Num,Gap,P). 
thais(Tl,T3,Gap,P):- 

that(Tl,T2), 

assertion(T2,T3,ihais,Gap,P). 
vo(Vl,V41,Gap,Num,Pl,P4)  ;- 

object(V3,V4,0,Sts2,Gap,vo,Pl,P2,PSA,P4), 

vb(Vl,V2,Slsl,Num,P2j, 

@(PA1J'A2,PSA), 

sas(V2,V3,Stsl,Sls2,PAl), 

sao(V4,V41,0,PA2). 
vingo(Vl,V41,Gap,Pl,P4):- 

object(V3,V4,0,Sis2,Gap,vingo,PlJ>2,PSAJ'4j, 

ving(Vl,V2,StslJ>2), 

@(PA1J'A2,PSA), 

sas(V2,V3,Sisl,Sts2,PAl), 

sao(V4,V41,0,PA2). 
veno(Vl,V41,Gap,Pl,P4);- 

object(V3,V4,0,Sls2,Gap,veno,Pl,P2,PSA,P4), 

ven(Vl,V2,Stsl,P2), 

@(PA1J'A2,PSA), 

sas(V2,V3,Slsl,Sts2,PAl), 

sao(V4,V41,0,PA2). 
venpass(Vl,V5,GapJ'l,P)  :- 

@([P2,[subject,anyone]IP4]J>SAJ'), 

ven(Vl,V2,Sts,P2), 

passobj(V3,V4,0,Pl  J*2,P4), 

(a)(PAlJ'A2,PSA), 

sa(V2,V3,PAl), 

sao(V4,V5,OJ'A2). 
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venpass(Vl,V6,GapPl,P)  :- 

@([P2,[subjcctJ'4]IP5],PSA,P), 

ven(Vl,V2,S,P2), 

passobj(V4,V5,0,Pl  J>2  ^5), 

passagent(V3,V4,Gap,P4), 

(a)(PAlJ'A2,PSA), 

sa(V2,V3,PAl), 

sao(V5,V6,OJ'A2). 
venpass(Vl,V6,Gap,Pl,P)  :- 

@([P2,[subjcci.P5]lP4],PSA.P), 

ven(Vl,V2,S,P2), 

passobj(V3,V4,pnJ'l,P2J>4), 

passagent(V4,V5,Gap,P5), 

@(PA1,PA2,PSA), 

sa(V2,V3,PAl), 

sa(V5,V6,PA2). 
sao(Sl,Sl,null,[]):-  !. 
sao(S],S2,nullJP):-!,fail. 
sao(Sl,S2,0,P) :-  sas(Sl,S2,[any],PV,P). 
sa(Sl,S2,P) :-  sas(Sl,S2,[any],PV,Pj. 
sas(Sl,S3,PVlJ'V3,[PllP2]):- 

saval(Sl,S2,PV],PV2,Pl), 

sas(S2,S3,PV2,PV3,P2), 
sas(Sl,Sl,PVlJ>V2,[])  :-  unisir(PVl,PV2), 
saval(Sl,S2,PVJ'V,[advJ>])  :-  adv(Sl,S2,P), 
saval(;Sl,S2J'Vl,PV2,P) :-  sava]l(Sl,S2.PVl,[]JPV2,P). 
sava]l(Sl,S2,[tovolPV],PVlJ^V2,P):-  !,savall(Sl,S2,PV.PVl,PV2,P). 
sava]l(Sl,S2,[niovolPV],PVl,PV2,P):-  l,sava]l(Sl,S2,PVJ'Vl,PV2,P). 
savall(Sl,S2,[nsigolPV],PVl,PV2,P):-  !,savall(Sl,S2,PV,PVl J'V2J'). 
savall(Sl,S2,[[pnlPN]IPV],PVl,PV2,P)  :-  !,savall(Sl,S2J'V,PVl  J>V2,P). 
savall(Sl,S2,[objecibelPV]J'Vl,PV2,P):-!,savall(Sl,S2J'VJ'Vl,PV2J'). 
savall(Sl,S2,[OTHERlPV],PVl,PV2,P):- 

!,savall(Sl,S2,PV,[OTHERIPVl],PV2,P). 
savall(Sl.S2,[],[],[],P):-!,fail. 

savall(Sl,S2,[],PVJ'V,[in-order-lo,P])  ;- lovo(Sl,S2,nogap,pro,P). 
savall(Sl,S2,[],PV,PV,P):-pn(Sl,S2,nogap,PP,P). 
objecibe-verb(Sts) :-  mem(objeclbe,Sts). 
nsigo-verb(Sls) :-  mem(nstgo,Sis). 
tovo-verb(Sts) :-  mem(iovo,Sis). 
nullobj-verb(Sls) :-  mem(nullobj,Sts). 
pn-verb(Sls,PP) :-  mem([pnlPP],Sls). 
vb(X,Y,Sts,Num,V) :-  verb(X,Y,Sls,Num,V),!. 
vb(X,Y,Sis,Num,V) :-  ven(X,Y,Sts,V),!. 
vb(X,Y,Sts,Num,V) :-  ving(X,Y,Sls,V),!. 

auxverb(Vl,V2,StsJ^um,P)  :- def(verb,P,aux,Sls),!,vrb(Vl,V2,Num,P). 
auxverb(Vl,V2,StsJJum,P):- vrb(Vl,V2>IumJ'),def(verb,P,aux,0sij,@(X,Sts,0st). 
verb(Vl,V2,StsJ^um,P) :-  def(verb,P,Aux,Sts),!,vrb(Vl,V2J4umJ'). 
verb(Vl,V2,StsJMum,P):-vrb(Vl,V2,Num,P),def(verbJ',Aux,Ost),@(X,Sts,Ost). 
ven(Vl,V2,Sls,P)  :-  vrb(Vl,V2,enJ'j,dcf(verb,P,Aux,Sls),!. 
ven( V 1  ,V2,Sls,P)  :-  vrb( V 1  ,V2,en J>),def(verb,P.Aux,Osl),@(X,Sts,Osi). 
vijig(Vl,V2,StsJ') :-  vrb(Vl,V2,ing,P),def(verbJ',Aux,Sts),!. 
ving(Vl,V2,StsP):-vrb(Vl,V2,ing,P),def(verb,P,Aux,Ost),@(X,Sls,Ost). 
unistr(S,S) :-  !. 

unisu([EISl],[EIS2])  :-  unistr(Sl,S2). 
unisir([EISl],S2) :-  @(X,[EIY],S2),(a)(X,Y,S3),!,unistr(Sl,S3). 
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Appendix  C:  A  lexicon  for  a  fragment  of  English 

vrb([arrivediV],V,sg,arrive). 

vrb([arrivedlV],V,pI,arrive). 

vrb([arrivelV],V,pl,arrive). 

vrb([arrivelV],V,inf,arrive). 

vrb([seemslV],V,sg,seem). 

vrb([wantlV],V,pl,want). 

vrb([wamlV],V,inf,wanij. 

vrb([wantslV],V,sg,want). 

vrb([eailV],V,inf,eai). 

vrb([eatlV],V,pl,eat). 

vrb([atelV],V,sg,eat). 

vrb([aielV],V,pl,eai). 

vrb([eatslV],V,sg,eat). 

vrb([lookslV],V,sg,look). 

vrb(ilooklV],V,pl,lookj. 

vrb([looklV],V,inf,look). 

vrb([likelV],V,inf,like). 

vrb([likclV],V,pl,like). 

vrb([likeslV],V,sg,likc). 

vrb(lbclV],V,inf,bc). 

vrb([islV],V,sg,be). 

vrb([arelV],V,pl,be). 

vrb([werelV],V,pl,be). 

vrb((doeslV],V,sg,do). 

vrb([dolV],V,pl,do). 

vrb([didlV],V,sg,do). 

vrb([didlV],V,pl,do). 

vrb([nylV],V,pl,ny). 

vrb([fiylV],V,inf,fly). 

vrb([nieslV],V,sg,fly), 

vrb([timelV],V,pl,iimc). 

vrb([limelV],V,inf,time). 

def(verb,arrive,naux,[nullobj]). 

def(verb,seem,naux,[tovo]). 

def(verb,wani,naux,[[ovo,nsigo]). 

def(verb,eal,naux,[nstgo]). 

def(verb,like,naux,[nsigo]). 

def{verb,be,aux,[objecibe]). 

dcf(verb,do,aux,[nsigo]). 

def(verb,look,naux,[nullobj,[pn,at]]). 

def(verb,fly,naux,[nullobj,nstgo]). 

def(verb,time,naux,[nstgo]). 

noun([johnlN],N,sg,john). 

noun([mar>'IN]>I,sg,mary). 

noun([manlN],N,sg,man). 

noun([menlN],N,pl,man). 

noun([fishlN]J^,X,fish). 

noun([doglN]J>I,sg,dog). 

noun([dogslN]>I,pl,dog). 

noun([mondaylN]J^,sg,monday). 

noun([timelN],N,sg,lime). 

noun([flieslN]jNl,pl,fly). 

noun([arrowlN]J^l,sg,arrow). 

noun([planeslN]J^,pI,plane). 

adj([talllA],A,lall). 
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adj([umelA],A,time). 

adj((happylA],A,happy). 

adj([clangeroaslA],A,dangerous). 

dei([alD],D,sg,a). 

det([anlD],D,sg,an). 

det([somelD],D,X,some). 

dei([everylD],D,sg,every). 

dei([alllD],D,pl,every). 

counl([si.xlQ],Q,pl,six). 

to([tolT],T), 

pro([helP],P,sg,he). 

pro([himlP],P,sg,he). 

pro([youlP],P,pl,you). 

whword([wholW],W,[ipos,who]). 

whword([whichlW],W,[tpos,which]). 

whword([whailW],W,[tpos,\vhat]). 

where([v,herelW],W, where). 

whques([wherelW],W,where). 

whqucs([hov.i\V],\\',how). 

vrb([eaienlVj,V,en,cai). 

vrb([arrivedlV],V,en,arrivej. 

vrb([likedlV].V,en,likej. 

vrb([beenlV],V,en,be). 

vrb([donelV],V,en,do). 

vrb([eatinglV],V,ing,eat). 

vrb([bcinglV],V,ing,be). 

vrb([doinglV],V,ing,doj. 

vrb([arrivinglV],V,ing, arrive). 

vrb([nyinglV],V,ing,fly). 

by(lbylB].B,by). 

lhat([lhailT],T). 

wh-that([thallT],T). 

wh-thai([wholT],T). 

prepCilolPlPjoj. 

prep([likelP],P,like). 

prep([onlP],P,onj. 

prep([inlP],P,in). 

prep([a[IP],P,ai). 

adv([quickJylA],A,quickly). 

adv([earlylA],A,early). 

adv([yesterdaylA],A,yesterday). 

adv([dangerouslylA],A,dangerously). 
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